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Summary 


Some  experienced  developers  of  hard  real-Jime  embedded  defense  systems  have  complained  about 
problems  with  the  Ada  programming  language.  These  problems  are  real,  but  resourceful  appli¬ 
cation  builders  and  Ada  language  implementors  are  finding  effective  ways  to  work  around  them. 
Unfortunately,  these  solutions  are  based  on  special  features  of  particular  Ada  compilation  systems. 

They  may  involve  subtle  compiler-dependent  application  code,  and  expensive  modifications  to  the 
compiler  or  Ada  runtime  system  to  fit  a  particular  application.  Whether  we  can  solve  the  problems 
of  programming  real-time  systems  in  Ada  is  therefore  not  so  much  an  issue  as  whether  we  can 
provide  economical,  and  preferably  standard^  Ada  solutions  to  these  problems.  —  ^ 

-  Modification  to  the  Ada  standard  is  not  a  sufficient  solution,  especially  in  the  short  term.  Despite 
the  benefits  of  commonality,  it  is  unwise  to  rush  to  lock  in  solutions  to  problems  that  are  not 
yet  well  understood  in  standards  as  rigorous  as  the  Ada  language.  Moreover,  real-time  cystems 
typically  have  inherent  hardware-dependencies.  Thus,  there  appears  to  be  a  need  for  more  capa¬ 
bility  to  economically  adapt  Ada  language  implementations  to  meet  the  special  needs  of  real-time 
applications,  based  on  existing  Ada  compilation  technology  and  within  the  current  Ada  standard. 

Most  of  the  features  needed  by  real-time  applications  can  be  implemented  within  the  Ada  runtime 
system  (RTS  for  short).  This  is  fortunate,  since  producing,  validating,  and  maintaining  custom 
versions  of  an  Ada  compilers  is  very  costly.  Ada  runtime  systems  are  much  smaller  and  simpler  \ 
than  compilers.  If  there  is  a  clean  and  well-specified  intenace  to  important  RTS  modules,  those 
modules  may  be  customized  without  compiler  modification. 


The  existence  of  weU-defined  interfaces  is  a  key  to  RTS  customization.  This  can  be  approached 
at  several  levels.  One  of  these  is  represented  by  the  Model  Runtime  System  Interface  [MRTSI], 
which  specifies  an  interface  between  the  code  generated  by  a  compiler  and  the  RTS.  If  adopted  by 
compiler  vendors,  this  interface  could  encourage  the  development  and  more  widespread  availability 
of  Ada  runtime  systems  designed  to  specifically  support  embedded  real-time  applications.  A  second 
important  level  of  interface  is  within  the  RTS,  between  modules  that  are  likely  to  need  application- 
specific  tailoring  and  the  rest  of  the  RTS.  A  third  level  of  interface  that  appears  useful  is  between 
the  application  program  and  modules  within  the  RTS  that  are  of  direct  use  to  the  application. 


V 


1  Introduction 


Despite  the  strengths  of  the  Ada  program njing  language,  as  compared  to  assembly  language  or  other 
existing  high-order  languages,  some  experienced  developers  of  real-time  embedded  systems  do  not 
believe  Ada  meets  their  needs;  they  fear  that  using  Ada  may  require  sacrificing  both  productivity 
and  quality.  This  situation  is  disturbing,  especially  in  view  of  the  increasing  reliance  being  placed 
on  software  in  critical  defense  systems,  and  the  increasing  complexity  of  this  software.  In  this 
report,  we  describe  some  of  the  problems  encountered  using  Ada  for  developing  real-time  systems, 
and  attempt  to  describe  possible  solutions  to  some  of  these  problems.  We  focus  in  particular  on 
the  ways  in  which  the  development  of  economical  solutions  to  these  problems  can  be  encouraged 
through  well-defined  runtime  system  interface  conventions. 

Section  2  enumerates  some  general  problem  areas  and  issues  related  to  using  Ada  for  real-time 
embedded  applications.  In  Section  3  we  outline  some  approaches  for  dealing  with  these  problems, 
including  RTS  extensions,  and  the  potential  benefits  of  standard  interfaces.  Section  4  we  describe 
work  we  have  done  toward  defining  one  important  level  of  RTS  interface,  the  Model  Runtime  System 
Interface  (MRTSI).  Part  of  this  work  has  been  development  of  a  prototype  MRTSI  implementation, 
to  help  verify  the  interface’s  feasibility,  which  is  also  described  in  this  section.  (More  details  of  this 
prototype ^are  provided  in  Appendices  A  and  B.)  Section  5  summarizes  the  results  of  our  studies. 


2  Real-Time  Ada  Problems  and  Issues 


The  effort  that  produced  the  Ada  language  was  originally  justified  on  the  grounds  that  existing 
high-order  languages  did  not  adequately  meet  the  needs  of  real-time  embedded  systems.  Now  that 
Ada  is  a  reality,  we  find  that  it  has  met  most  of  those  needs,  left  some  others  unmet,  and  also 
introduced  some  new  problems. 


2.1  Real-Time  Software 

Real-time  computer  applications  are  characterized  by  interaction  with  real-world  (physical)  events, 
over  whose  timing  they  have  little  or  no  control.  It  is  therefore  a  requirement  of  the  software  that 
it  control  its  own  execution  timing  so  as  to  synchronize  with  the  real  world.  If  the  timing  of  the 
software  does  not  meet  certain  “hard”  constraints,  the  entire  system  of  which  the  software  is  a  part 
may  fail.  Where  the  likelihood  and  consequences  of  failure  to  meet  a  hard  timing  constraint  are 
sufficiently  serious,  achieving  correct  timing  becomes  a  central  design  goal. 

Besides  timing  constraints,  real-time  systems  typically  have  a  number  of  important  secondary  char¬ 
acteristics,  which  derive  from  their  typical  function,  which  is  monitoring  and  controlling  physical 
processes.  These  characteristics  include  concurrency,  high  reliability  and  fault  tolerance,  resource 
constraints  (memory,  power,  and  weight),  and  low-level  interactions  between  the  software  and 
application-specific  hardware  devices.  Many  newer  real-time  systems  demonstrate  additional  char¬ 
acteristics,  due  to  increasingly  ambitious  application  goals.  These  include  complexity,  distribution 
over  several  processors,  and  very  long  lifetimes.  The  latter  in  turn  implies  the  application  must  be 
extensible  and  adaptable  to  new  processors  amd  peripheral  hardware. 
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Real-time  softwaxe  ha^  traditionally  been  developed  in  a  combination  of  assembly  language  and 
higher-order  language  (e.g.  FORTRAN,  PASCAL,  JOVIAL,  CMS2).  The  use  of  higher-order 
languages  has  been  mostly  limited  to  components  for  which  most  high  order  languages  would 
be  adequate  -  that  is,  computational  algorithms.  Very  time-critical  components,  interfaces  to 
hardware  devices,  and  scheduling  and  resource  management  functions  have  been  programmed  in 
assembly  language.  The  latter  functions  are  typically  isolated  in  an  “executive”,  which  may  be 
partly  standardized,  but  is  ordinarily  tuned  to  the  specific  requirements  of  each  application. 

There  are  problems  with  this  way  of  developing  software.  Chief  of  these  is  that  it  requires  a  great 
deal  of  highly  skilled  labor.  Also,  because  of  the  level  of  detail  that  must  be  mastered,  it  does  not 
scale  up  well  to  larger  projects.  A  third  problem  is  that  existing  real-time  programs  tend  to  be 
“brittle”;  they  break  if  one  attempts  to  modify  them.  Nevertheless,  this  traditional  approach  does 
work,  and  there  are  people  who  have  experience  with  it. 


2.2  Ada’s  Conflicting  Philosophical  Origins 

Perhaps  one  of  the  problems  with  Ada  as  a  real-time  language  is  that  the  designers  were  out  of  touch 
with  the  practice  of  real-time  programming.  One  gets  this  feeling  by  reading  the  Ada  Rationale 
[Rat],  the  'references  it  cites,  and  the  other  issues  of  SIGPLAN  Notices  around  that  time.  The 
flavor  of  the  prevalent  philosophy  among  programming  language  enthusiasts  might  be  conveyed  by 
the  following  idealistic  assertions,  which  were  widely  held  at  that  time: 


•  The  best  way  to  design  is  top-down,  working  from  well-defined  requirements. 

•  The  direction  of  progress  is  toward  ever  more  use  of  automation,  standardization,  and  ab¬ 
straction. 

•  Reducing  the  use  of  assembly  language  will  increase  programmer  productivity,  reduce  the 
level  of  skin  required  of  programmers,  and  make  it  easier  to  modify  programs  correctly. 

•  Standardization  on  one  high-order  language  will  reduce  dependence  on  specialized  program¬ 
mers,  and  reduce  the  need  for  new  software  by  allowing  more  code  to  be  re-used. 

•  Much  of  the  detailed  design  work  involved  in  producing  software,  including  that  concerned 
with  scheduling  to  meet  timing  constraints,  can  be  automated;  such  automation  will  result 
in  better  and  cheaper  systems. 


Enlightened  believers  in  these  principles  held  them  in  a  regard  that  was  something  between  ax¬ 
iomatic  and  moralistic. 

The  requirement  definition  process  for  Ada  brought  in  a  wide  variety  of  people,  with  different 
philosophies  and  experiences.  These  included  experienced  real-time  programmers.  Looking  at  the 
requirements  this  group  produced,  we  can  see  the  influence  of  pragmatic  minds,  who  probaoly 
recognized  that  principles  like  those  above  do  not  apply  quite  so  well  to  real-time  software  as  they 
may  in  other  contexts: 
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•  Top-down  design  does  not  work  well  when  requirements  are  not  well-defined  or  subject  to 
change,  or  when  the  designer  does  not  have  siifficient  experience  to  choose  decompositions 
that  are  efficiently  implementable  at  lower  levels. 

•  Automation  only  leads  to  savings  when  applied  to  essentially  repetitive  tasks  and  when  the 
volume  of  production  is  sufficient  to  offset  the  cost  of  automation. 

•  Standard  products  frequently  don’t  quite  fit  our  requirements.  (Consider,  for  example,  shoes 
and  feet.)  Ideally,  the  illness  of  fit  is  offset  by  the  economy  of  using  the  standard,  but  there 
are  cases  where  insistence  on  using  a  standard  that  does  not  fit  can  be  crippling. 

•  Abstraction,  as  traditionally  applied  to  programming  language  semantics,  throws  away  many 
details  that  are  sometimes  critical  in  real-time  systems,  such  as  the  machine  representation 
of  data  and  exact  execution  timing. 

Thus,  while  the  Ada  requiments  specify  a  general-purpose  high-order  algorithmic  language,  they 
also  clearly  state  that  programmers  should  have  the  option  of  taking  explicit  control  over  critical 
low-level  details.  For  example,  the  1978  Ironman  document  [Iron]  says  “it  shall  be  possible  to  use 
object  machine  features  directly  in  programs”.  This  and  some  other  similaj  requirements  were 
honored  in  the  language  design,  and  are  traceable  forward  to  features  in  present-day  Ada.  On  the 
other  hand,  we  see  places  where  the  idealists  appear  to  have  triumphed. 

Examples  of  places  where  idealism  appears  to  have  overcome  pragmatic  considerations  include  the 
Ironman  requirements  that  “The  baUt-in  mutual  exclusion  and  synchronization  facilities  shall  be 
sufficiently  low-level  to  permit ...  user  definition  of  more  specialized  mechanisms,”  and  “Within  any 
parallel  control  structure  it  shall  be  possible  to  dynamically  alter  the  relative  priorities  of  the  the 
paths.”  Such  unmet  requirements  account  for  most  of  the  present  problems  with  Ada  for  real-time. 


2.3  Early  Problems  with  Ada 

At  first  it  seemed  that  Ada  created  more  problems  than  it  solved.  There  were  no  software  tools 
available,  no  existing  body  of  code  that  could  be  re-used,  and  no  experienced  programmers.  The 
first  Ada  implementations  were  not  very  good,  either. 

The  first  Ada  compilers  were  large,  slow,  unreliable,  consumed  a  terrific  amount  of  disk  space,  and 
were  awkward  to  use.  They  produced  code  that  was  grossly  inefficient,  in  terms  of  both  size  and 
speed.  These  compilers  were  designed  to  execute  and  generate  code  for  main-frame  computers  run¬ 
ning  general-purpose  operating  systems.  Because  the  low-level  programming  features  of  Ada  were 
optional,  and  not  needed  in  this  environment,  they  were  not  implemented.  For  similair  reasons, 
tasking  operations  were  very  slow.  Because  these  compilers  were  targeted  to  virtual  memory  ma¬ 
chines,  they  made  no  attempt  to  avoid  linking  useless  runtime  system  components.  The  program 
images  were  therefore  frighteningly  large. 

The  language-lawyers  amd  bureaucrats  did  not  help  either.  They  constantly  harped  about  vadidation 
and  full  compliance  with  the  Ada  standard  down  to  its  last  waxt  and  mole  (but  not  the  optional 
features  needed  by  real-time  programmers).  This  diverted  effort  from  achieving  better  object- 
program  performance,  and  discouraged  efforts  to  correct  flaws  and  shortcomings  of  the  language. 
(As  compared,  for  example,  to  the  free  evolution  of  Pascad  and  Modulai2.) 
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Another  problem  was  the  “bundling”  of  Ada  with  huge  integrated  programming  environments. 
The  Ada  implementation  was  viewed  as  a  closed  system,  integrating  all  the  functions  traditionally 
provided  by  separate  software  components,  including  executive,  input-output  (I/O)  system,  linker, 
loader,  editor,  and  software  library  manager.  This  seemed  to  raise  the  cost  and  risk  of  using  Ada., 
since  proven  tools  would  have  to  be  replaced  by  new  untested  ones.  Worse,  since  compiler  developers 
invented  their  own  closely  closely  held  interfaces  between  tools,  if  one  of  these  components  should 
not  prove  adequate  as  provided  by  the  compiler  vendor,  there  appeared  to  be  no  way  for  the 
customer  to  modify  or  replace  it. 


2.4  Ada  Today 

Fortunately,  these  problems  are  largely  past.  Many  people  have  lecimed  ajid  aire  teaching  Ada.  The 
body  of  reusable  Ada  code  is  rapidly  growing,  as  is  the  number  of  Ada  software  tools.  Today’s  Ada 
compilers  are  much  better.  They  are  faster,  partly  due  to  compiler  improvements  and  partly  due  to 
advances  in  low-cost  computers  and  disk  drives.  The  best  Ada  compilers  generate  code  comparable 
in  size  and  speed  to  that  generated  by  compilers  for  other  languages.  Some  are  now  supporting  all 
of  Ada’s  optional  features,  including  in-line  machine-code  procedures.  Linkers  now  discard  unused 
code,  and  runtime  systems  are  smaller  and  faster.  The  language  bureaucrats  have  gotten  their 
priorities  straight,  so  that  validation  no  longer  is  a  serious  obstacle  to  producing  usable  compilers. 
Even  the  problem  of  bundling  has  faded  slightly,  so  that  some  of  today’s  compilers  follow  object 
code  conventions  compatible  with  standard  operating  system  tools,  including  compilers  for  other 
languages.  In  short,  Ada  has  caught  up  with  other  languages. 

Now  that  most  of  Ada’s  early  developmental  difficulties  axe  over,  we  can  more  accurately  evaluate 
its  suitability  for  writing  real-time  software,  and  focus  more  cleaxly  on  solutions  to  its  remaining 
problems.  However,  before  turning  to  criticize  Ada,  we  must  be  careful  to  define  the  standard 
against  which  we  will  measure  it.  The  first  standard  we  should  apply  is  established  by  other 
available  programming  languages.  As  compared  to  these,  we  will  see  that  Ada  looks  good.  The 
second  standard  by  which  we  must  judge  Ada  is  that  established  by  existing  real-time  operating 
systems  or  executives  (executives,  for  short).  This  may  seem  unfair,  especially  since  Ada  doesn’t 
come  out  very  well,  but  Ada  forces  the  comparison  by  getting  involved  in  concurrent  programming. 
Finally,  we  can  measure  Ada  against  directly  against  the  characteristic  requirements  of  real-time 
systems,  but  remembering  that  we  are  comp<«xing  a  reality  against  an  ideal.  We  will  see  that  Ada 
has  gotten  off  to  a  good  staxt,  but  still  has  a  long  way  to  go. 


2.5  Ada  versus  other  Languages 

Overall,  as  compared  with  other  available  languages,  Ada  looks  very  good.  It  has  the  best-defined 
and  best-enforced  standard,  with  a  stringent  validation  process.  After  a  large  investment,  there 
are  now  many  conforming  implementations,  including  several  for  machines  that  are  well-suited  for 
real-time  applications.  Ada  supports  clean  interfaces,  through  strong  typing  and  packages.  It  is 
extensible,  through  packages,  generics,  attributes,  and  pragmas.  Many  of  the  implicit  dependen¬ 
cies  on  specific  compilers  and  computer  hardware  that  make  programs  written  in  other  languages 
difficult  to  port  can  be  eliminated  or  controlled,  using  Ada’s  attributes  and  representation  clauses. 

On  the  negative  side,  Ada  is  more  complex  than  other  standard  languages.  This  causes  several 
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problems.  Chief  uhese  is  that  compared  with  compilers  for  other  languages,  Ada  compilers  are 
still  large,  slow,  and  use  lots  of  permanent  file  space.  They  are  large  and  slow  because  Ada  requires 
more  compile-time  checking,  and  also  because  Ada  needs  more  optimization.  They  use  lots  of 
permanent  file  space  because  of  the  separite  compilation  library  facility. 

Ada’s  complexity  is  also  reflected  in  the  object  code  that  compilers  produce.  There  are  several 
language  features  that  require  complex  optimizations  in  order  to  achieve  acceptable  performance. 
These  include  nonstatic  sized  arrays  and  records,  aggregates,  recursion,  runtime  checks,  and  tasking. 
Because  of  the  complexity  of  the  compiler  code  that  performs  these  optimizations,  there  is  more 
chance  of  compiler  bugs.  There  may  also  be  performance  surprises,  when  expected  optimizations 
are  not  applied,  and  errors,  when  a  compiler  applies  an  optimization  in  a  context  where  it  is  unsafe. 

Several  Ada  features,  including  separate  compilation,  overloading,  and  static  expression  evaluation, 
make  the  automatic  processing  and  transformation  of  Ada  source  code  difficult.  This  makes  software 
tools  for  Ada  inherently  more  complex  than  for  other  languages,  and  therefore  more  expensive. 
Fortunately,  this  extra  cost  has  not  prevented  the  development  of  Ada  tools. 

Reliable  formal  verification  of  Ada  programs  is  made  more  diffictdt  for  Ada  than  some  other  lan¬ 
guages  by  its  more  complex  features,  especially  exception  handling  and  task  abortion.  It  is  also 
made  unreliable  by  aspects  of  the  Ada  semantics  that  the  Standard  leaves  unspecified,  but  this  is 
also  true  of  other  languages.  Moreover,  the  practicality  of  formal  verification  of  whole  programs  is 
already  questionable,  regardless  of  language. 

Bundling  Ada  compilers  with  other  software  components  remains  a  problem,  though  it  is  perhaps 
not  as  severe  as  it  once  was.  This  problem  is  more  or  less  inherent  in  the  Ada  language  definition, 
which  imposes  specific  requirements  on  the  functions  of  the  executive,  I/O  system,  linker,  loader, 
and  software  library,  and  their  interactions.  As  a  consequence,  Ada  is  often  criticized  for  problems 
that  one  would  not  ordinarily  blame  on  a  programming  language. 

There  are  several  directions  in  which  Ada  reaches  outside  the  traditional  programming  language 
domain.  First,  by  specifying  a  model  of  concurrent  programming,  Ada  intrudes  into  the  domain  of 
the  executive.  Examples  of  this  intrusion  include  task  priorities,  delays,  hardware  interrupt  entries, 
intertask  data  sharing,  and  notification  of  certain  exceptions.  Second,  by  requiring  compile-time 
checking  across  all  the  sepairately  compiled  units  of  a  program,  Ada  intrudes  into  the  domains  of 
the  program  library  manager  and  linker.  Ada  compilations  systems  intrude  further  into  the  domain 
of  the  linker  when  they  attempt  optimizations  that  require  global  information.  Finally,  to  a  lesser 
extent,  Ada  intrudes  into  the  I/O  system  through  the  standard  I/O  packages  and  the  ability  to 
bind  hardware  interrupts  to  task  entries. 

By  reaching  into  these  other  domains,  Ada  and  its  implementations  limit  a  programmer  more  than 
do  other  languages.  These  limitations  can  be  viewed  as  flaws  when  they  stand  in  the  way  of  getting 
a  job  done.  For  example,  if  a  system  designer  needs  to  use  deadline- based  task  scheduling  the  Ada 
priority  rules  get  in  the  way.  Suppose  the  designer  wishes  to  load  portions  of  his  program,  including 
code  and  certain  constant  tables,  into  read-only-memory.  Ada  provides  no  way  of  doing  this,  so  the 
linker  integrated  with  the  Ada  compiler  probably  won’t  allow  it.  What  if  a  programmer  wants  to 
update  a  running  program,  without  restarting  the  system?  ...  These  are  just  a  few  of  the  problems. 
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2.6  Ada  versus  an  Executive 


Because  Ada  intrudes  into  the  domain  of  the  real-time  executive,  by  supporting  features  like  concur¬ 
rent  execution,  delays,  and  task  priorities, It  preempts  the  application  programmer  from  installing 
his  own  executive.  However,  since  the  standard  Ada  language  does  em  not  provide  aU  the  services 
typically  provided  by  such  an  executive,  the  application  programmer  is  left  without  some  needed 
functionality.  An  Ada  implementor  can  choose  to  provide  additional  services,  but  hcis  no  recognized 
source  of  guidance  as  to  what  these  additional  services  should  be. 

An  example  of  this  sort  of  problem  is  how  to  program  a  collection  of  periodic  tasks  such  that 
if  a  task  misses  its  deadline  it  will  be  suspended  immediately,  regardless  of  its  priority.  Another 
example  is  how  to  insure  the  interleaved  execution  of  two  equal-priority  tasks  without  the  possibility 
of  processor  idle  time. 

Besides  appropriately  general  scheduling  primitives,  Ada  is  missing  some  important  abstractions 
that  are  normally  provided  by  an  operating  system  or  executive.  Examples  of  such  missing  abstrac¬ 
tions  include  the  concept  of  interrupt  (the  Ada  notion  of  an  address  is  not  adequate),  interrupt 
mask,  storage  area,  data  segment,  timer,  loadable  code  module,  recovery  unit,  and  processing  node. 
Other  abstractions  are  provided  in  only  a  crippled  form,  for  which  needed  operations  are  not  avail¬ 
able.  These  include  tasks,  exceptions,  procedures,  and  addresses.  For  example,  there  is  a  standard 
attribute  to  obtain  the  address  of  a  task,  procedure,  label,  or  object,  but  there  is  no  standard  way 
to  convert  an  address  back  to  one  of  these  entities. 

Ada  implementations  that  are  targeted  to  machines  with  standard  full-function  operating  systems 
typically  provide  extensions  that  permit  access  to  the  full  capabilities  of  the  underlying  system. 
However,  fundamental  semantic  incompatibilities  between  the  operating  system’s  process  model 
and  the  Ada  task  model  may  still  force  the  programmer  into  compromises,  such  as  discarding  .4da 
tasking  in  favor  of  “multiprogramming”.  (In  some  cases  this  may  be  a  good  idea.) 


2.7  Interaction  with  the  Real  World 

For  interaction  with  the  the  real  world,  Ada  allows  a  programmer  to  bind  interrupts  to  task  entries. 
The  Ada  implementation  may  map  some  interrupts  (more  properly  traps)  to  predefined  e.xceptions, 
but  the  programmer  cannot  bind  interrupts  to  exceptions.  This  model  is  helpful,  but  is  not  entirely 
adequate  in  several  respects: 


1.  There  is  no  way  to  disable  or  block  interrupts,  except  perhaps  implicitly  via  control  structures 
within  the  handler  task. 

2.  The  standard  way  of  naming  interrupts,  via  a  value  of  type  SYSTEM.  ADDRESS,  is  not  applicable 
to  most  architectures. 

3.  There  is  no  way  to  bind  interrupts  to  different  handlers  dynamically,  without  creating  and 
destroying  tasks. 

4.  There  is  no  way  for  a  hardware  interrupt  handler  to  reliably  wake  up  another  task,  that  may 
be  waiting.  This  appears  possible  using  a  rendezvous,  but  the  implementation  practicalities 
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of  interrupt  handlers  require  that  such  a  rendezvous  be  conditional  on  the  side  of  the  handler, 
so  that  waJceup  signals  may  be  missed. 

5.  There  is  no  way  for  an  interrupt  handler  to  preemptively  and  asynchronously  signal  an  ex¬ 
ecuting  task  to  change  its  thread  of  control.  This  means,  for  example,  that  if  an  interrupt 
handler  detects  that  another  task  is  about  to  miss  its  deadline,  or  detects  that  aji  external 
event  has  occurred  requires  the  task  to  change  its  priority  and  restart  with  new  data,  there 
is  no  way  for  the  handler  to  force  the  task  to  take  immediate  notice. 

6.  There  is  no  way  to  specify  how  an  interrupt  is  to  be  treated  when  the  task  with  the  corre¬ 
sponding  entry  is  not  ready  to  accept.  Specifically,  is  it  is  queued  or  is  it  lost? 

7.  There  is  no  standard  pragma  like  SHARED  for  array  and  record  structures,  to  insure  that  if 
access  to  a  buffer  is  shared  between  an  Ada  tasks  and  an  I/O  device  or  interrupt  handler 
the  compiler  will  insure  that  elements  of  the  buffer  are  read  from  and  written  to  memory 
immediately. 

2.8  Achieving  Correct  Timing 

Ada  gives  very  little  control  over  execution  timing.  Achieving  correct  timing  requires  several  things: 


1.  accurate  estimation  of  processor  time  and  other  resource  requirements  of  processes; 

2.  an  accurate  real-time  clock; 

3.  a  means  of  preempting  the  processor  for  certain  timed  events; 

4.  control  over  the  scheduling  of  all  resources  needed  by  time-critical  processes. 


Ada,  like  virtually  all  high  level  languages,  provides  no  information  about  the  execution  time  of  code 
sequences.  The  problem  is  slightly  aggravated  by  Ada’s  complexity.  Ada  aggravates  this  problem 
further  by  including  dynamic  storage  allocation  features  that  may  cause  an  implementation  to 
perform  time-consuming  storage  allocation  and  reclamation  operations  at  unpredicatable  times. 

Ada  does  provide  a  real-time  clock  (2)  in  the  form  of  CALENDAR. CLOCK,  but  without  any  assurance 
of  accuracy,  and  with  no  specification  of  how  or  when  this  clock  may  be  reset,  or  whether  it  may 
occasionally  jump  backward.  The  range  and  precision  of  the  type  of  value  returned  by  this  clock 
make  it  inefficient  for  most  real-time  uses,  since  it  is  too  long  to  be  read  and  written  atomically  on 
a  machine  with  less  than  64-bit  operations. 

Ada  does  not  provide  a  preemptive  timer,  except  possibly  via  machine-dependent  linkage  to  an 
interrupt  generated  by  a  hardware  timer.  This  is  likely  not  to  be  readily  available  since  in  many  cases 
the  Ada  RTS  will  already  rely  on  having  exclusive  use  of  the  only  available  hardware  timer(s),  for  the 
implementation  of  CALENDAR. CLOCK  and  delays.  The  delay  statement  provides  a  form  of  relative 
time  delay  with  no  known  accuracy,  no  guaranteed  upper  bound,  and  no  specified  relationship  to 
CALENDAR.  CLOCK.  Because  the  reading  of  the  clock,  calculation  of  delays,  and  execution  of  the  delay 
statement  are  all  preemptable,  there  is  no  way  of  achieving  an  accurate  absolute  or  periodic  wakeup 
event.  Some  sort  of  virtual  periodic  amd  absolute  timers  therefore  should  be  provided. 
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Static  task  priorities  are  provided,  but  they  are  optional,  and  crippled  in  several  ways.  First  of  all, 
they  axe  assigned  to  task  types,  rather  than  task  objects.  Second,  they  are  assigned  statically,  which 
causes  difficulty  adapting  scheduling  to  changing  real-world  requirements  (e.g.,  modes).  Third, 
there  are  anomalies  between  the  priority'scheme  and  the  semantics  of  entry  calls[CSLRT].  For 
example,  while  the  priority  of  a  calling  task  is  inherited  by  the  accepting  task,  this  does  not  take 
place  until  a  rendezvous  begins.  Thus,  if  the  accepting  task  is  not  ready  to  accept,  a  high  priority 
caller  and  its  acceptor  may  wait  forever  while  middle-priority  tasks  execute.  Similar  anomalies  can 
arise  whtn  the  FIFO  entry  service  policy  causes  a  high  priority  task  to  be  queued  behind  a  low 
priority  one,  and  when  the  incompletely  specified  semantics  of  selective  waits  allows  a  low  priority 
call  to  be  a.ccepted  ahead  of  a  high  priority  one. 

Ideally,  Ada  should  provide  the  freedom  (and  means)  to  devise  and  implement  application-specific 
scheduling  policies.  This  means  there  should  be  at  least  a  way  to  change  priorities  and  to  suspend 
and  resume  tasks.  A  standard  priority-based  scheme  for  consistent  cpu-scheduling  and  rendezvous 
is  also  needed,  with  a  guaranteed  minimtim  range  of  priori ties[CSLRT]. 

Ada  also  hides  or  takes  away  memory-related  choices  (as  described  below),  that  may  affect  timing 
in  a  hierarchical  memory  system. 


2.9  Control  over  Memory  Usage 

Ada  provides  some  control  over  memory  usage.  Specifically  Ada  has: 

1.  the  STQRAGE.SIZE  representation  clause  for  tasks; 

2.  the  STORAGE.SIZE  representation  clause  for  access  t3rpes,‘ 

3.  the  pragma  CONTROLLED  for  access  types; 

4.  the  generic  subprogram  UNCHECKEO.DEALLOCATION,  for  access  objects; 

5.  other  representation  clauses  for  data  types. 

The  first  problem  with  these  mechanisms  is  that  they  are  optional,  and  in  the  case  of  pragmas 
cam  be  ignored  without  comment.  The  second  problem  is  that  the  effects  of  these  features  a^e 
imprecisely  defined.  For  example,  does  the  storage  size  of  a  task  include  storage  for  objects  of 
access  types  declared  within  the  task?  How  about  storage  for  local  tasks  within  it?  How  about 
other  heap  storage,  for  implicitly  created  temporary  objects  of  dynamic  size  within  the  task?  Is 
this  included  within  the  storage  of  the  task?  Can  this  storage  be  relied  upon  to  be  contiguous? 
How  much  of  this  storaige  is  overhead?  How  efficient  is  the  allocation  and  recovery  mechanism;  i.e., 
how  much  will  be  wasted  due  to  fragmentation?  Similar  questions  can  be  raised  about  storage  for 
access  objects. 

The  third  problem  is  that  there  are  many  storage  management  issues  not  addressed  by  any  Ada 
feature,  no  matter  how  imprecisely  defined.  For  example:  How  can  objects  be  assigned  to  read-only 
memory  (ROM)  versus  random-access  memory  (RAM)?  How  about  between  shared  multiprocessor 
memory  and  local  memory?  How  can  specific  data  be  clustered  within  a  single  page,  or  aligned 
on  page  or  segment  boundaries?  If  there  is  virtual  memory,  how  can  specific  objects  or  code  be 
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locked  into  physical  memory?  How  can  specified  code  or  data  be  prefetched  at  a  scheduled  time,  or 
locked  into  RAM,  so  that  it  will  be  resident  when  needed?  How  can  certain  sections  of  memory  be 
protected  against  accidental  overwriting?  Control  over  such  choices  is  often  provided  by  traditional 
executives,  and  could  be  provided  in  Ada*via  appropriate  extensions. 


2.10  Concurrent  Programming 

The  reasons  for  including  concurrent  programming  (taisking)  in  a  programming  language  are  conve 
nience  and  commonality.  By  enforcing  use  of  one  standard  model  of  concurrency,  the  language  can 
make  it  easier  for  people  to  understand  one  another’s  programs  and  save  time  that  might  otherwise 
be  spent  on  developing  an  application-specific  executive.  Were  it  not  for  these  reasons,  equivalent 
functionality  could  just  as  well  be  provided  via  service  calls  to  an  underlying  operating  system  or 
executive  (executive,  for  short).  Moreover,  if  the  interface  to  this  executive  is  standardized,  the 
goal  of  commonality  is  also  met.  The  only  good  reason  for  including  tasking  as  part  of  the  Ada 
language  is  therefore  the  notational  convenience  of  special  syntactic  forms. 

An  immediate  negative  consequence  of  embedding  a  model  of  concurrency  into  Ada  is  that  it  con¬ 
flicts  with  other  established  models,  including  virtually  all  those  used  in  the  literature  of  scheduling 
theory  and  all  those  used  by  existing  standard  executives.  Of  course,  this  would  be  true  of  any 
attempt  to  impose  a  standard  model  of  concurrency,  including  a  standard  executive  interface,  so  if 
we  accept  the  need  for  a  standard  model  of  concurrency  this  is  not  an  issue. 

The  question  remains  whether  Ada’s  model  of  concurrency  is  adequate.  The  answer  to  this  question 
is  “not  entirely”.  The  Ada  tasking  model  appears  to  be  adequate  for  some  purposes,  but  inadequate 
for  others,  including  specifically  many  real-time  applications. 

Ada  supports  concxirrent  programming,  via  the  task  mechanism,  but  this  tasking  mechanism  has 
several  flaws.  The  main  problem  is  an  inappropriate  choice  of  primitives.  They  axe  inappropriate 
because  they  are  too  complex  to  be  efficiently  implemented,  and  because  they  need  to  be  used 
in  complex  combinations  to  perform  functions  that  are  frequently  needed  in  real-time  systems. 
The  semantics  of  task  creation  and  termination  are  especially  onerous.  The  rendezvous  is  also  too 
complex  to  be  the  lowest-level  method  provided  for  task  synchronization  and  mutual  exclusion. 
For  example,  coding  basic  operations  on  standard  concurrent  programming  abstractions  such  as 
buffers  and  monitors  requires  the  introduction  of  intermediary  tasks  and  multiple  rendezvous.  This 
is  gross  inefficiency,  as  is  revealed  by  examination  of  the  runtime  system  code  that  implements  the 
Ada  “primitives”.  This  code  itself  makes  use  of  more  natural  primitives,  such  as  buffers,  queues, 
and  semaphores! 

Of  course,  one  can  argue  that  traditional  primitives,  such  as  buffers  and  monitors,  are  too  low-level 
-  that  one  should  design  using  rendezvous,  eliminating  the  need  for  these  other  constructs.  (This 
does  not  address  some  other  big  issues:  data  sharing  between  tasks;  d3mamic  task  creation  and 
termination;  abortion.)  However,  experience  using  Ada  tasking  for  real-time  programming  has 
proven  that  this  belief  is  unfounded.  Rendezvous  rarely  is  useful  by  itself.  For  instance,  the  main 
reason  for  separating  a  program  into  tasks  is  to  deal  with  asynchronism  in  the  real  world.  By 
forcing  such  tasks  to  communicate  through  rendezvous,  they  are  forced  to  synchronize,  defeating 
the  purpose  of  the  original  separation.  We  are  then  forced  to  introduce  another  task,  and  another 
rendezvous,  where  what  we  really  wanted  was  a  simple  buffer. 
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Another  belief  is  that  Ada  compilers  should  rfecognize  Ada  “idioms”  for  frequently  used  concurrent 
programming  abstractions,  and  translate  them  into  simpler  constructs.  Thus,  a  task  whose  only 
role  is  to  serve  as  a  buffer  can  be  eliminated  and  the  rendezvous  replaced  by  simpler  read  and  write 
operations  on  the  buffer.  This,  too,  is  a  fallacy.  First  of  all,  the  conditions  under  which  this  sort  of 
“optimization”  can  be  performed  safely  are  difficult  to  recognize,  and  easy  to  violate  accidentally 
through  program  modifications.  Compilers  (and  programmers)  are  thus  forced  to  choose  between 
safety  and  performance.  Second,  portability  is  lost,  since  correct  timing  is  now  dependent  on  a 
compiler  being  able  to  translate  a  particular  idiom.  Finally,  the  Ada  source  code  is  still  difficxilt  to 
comprehend,  for  much  the  same  reasons  as  control  structures  constructed  out  of  gotos  are  harder 
to  understand  than  standard  control  structures  like  for  loops  and  if.. .then.. .else  statements. 

An  obvious  solution  to  this  problem  of  missing  primitives  is  to  export  truly  primitive  operations 
directly  to  the  programmer.  This  can  be  done  via  predefined  packages,  which  would  start  out  as 
implementation-dependent,  but  eventually  might  be  standaurdized.  This  is  simple,  direct,  reliable, 
economical,  and  presents  less  of  a  portability  problem  than  complex  compiler  optimizations.  If 
the  needed  predefined  packages  are  not  supported  by  a  particular  compiler,  they  can  be  written 
by  the  application  programmer  (ideally,  using  Ada  with  machine-code  inserts).  In  some  cases  this 
may  require  detailed  information  about  the  Ada  tasking  implementation,  but  this  is  less  work  than 
adding  tasking  optimizations  to  a  compiler. 

We  have  already  discussed  some  other  specific  problems  with  the  Ada  tasking  model,  underin¬ 
teraction  with  the  Real  World”  and  “Controlling  Execution  Timing”.  These  include:  priorities, 
which  are  presently  treated  inconsistently,  and  need  to  be  made  dynamic  for  some  applications; 
scheduling  support  for  periodic  processes;  an  immediate  task  restart  capability;  a  way  to  reliably 
and  asynchronously  forward  events  requiring  an  immediate  response  from  interrupt  handlers  to 
other  tasks.  Major  deficiencies  in  the  tasking  model  which  we  have  not  discussed  include  the  need 
for  some  way  of  identifying  tasks  of  heterogeneous  types  via  a  single  data  type,  as  in  the  context  of 
schedulers  and  other  resource  managers,  and  the  need  for  a  non-blocking  form  of  message-passing 
between  tasks. 


2.11  Reliability 

In  many  ways,  Ada  aids  the  production  of  reliable  software,  by  strong  type  checking  and  by  the 
package  mechanism,  which  encourages  clean  separation  of  concerns.  For  situations  where  the 
standard  Ada  tasking  model  is  adequate,  it  may  contribute  to  reliability,  by  eliminating  the  need 
for  the  application  programmer  to  be  concerned  with  the  complexity  of  programming  an  executive. 

The  main  obstacle  to  reliability  imposed  by  Ada  is  its  complexity.  This  increases  the  likelihood 
of  programmer  errors  as  well  as  language  implementation  errors  (as  discussed  in  Section  2.5). 
There  are  several  interesting  examples  of  compiler  errors  that  have  cause  intermittent  faults,  and 
programming  errors  that  may  not  cause  a  fault  until  after  a  program  has  been  running  for  a  very 
long  time.  One  example  is  when  a  program  uses  a  task  access  type  to  create  a  short-lived  task 
in  response  to  an  infrequent  event.  In  some  implementations,  the  small  residual  storage  occupied 
by  such  tasks  after  they  terminate  can  eventually  exhaust  storage,  but  not  until  a  long  time  has 
passed. 

A  secondary  problem  is  implementation-dependencies  over  which  no  mechanism  is  provided  for 
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explicit  control.  This  is  more  likely  to  cause  portability  problems,  but  might  also  cause  reliability 
problems  when  going  to  a  new  version  of  an  Ada  compilation  system.  For  example,  a  change  in  the 
default  processor-scheduling  algorithm  might  cause  a  multitask  program  to  stop  working  correctly. 


2.12  Fault  Tolerance 

Ada  does  a  little  to  help  with  fault-tolerant  design,  through  the  exception-handling  mechanism. 
This  has  some  weaknesses,  however.  Chief  among  these  weaknesses  is  that  no  provision  is  made 
for  one  task  (when  it  detects  an  error,  such  as  a  timing  fault)  to  raise  an  exception  asynchronously 
in  another  (to  cause  it  to  recover  from  the  error). 


2.13  Operating  within  Constrained  Resources 

The  problem  of  designing  an  Ada  program  to  operate  within  resource  constraints  has  already  been 
discussed.  Part  of  the  problem  is  a  consequence  of  language  complexity.  Fortunately,  Ada  compilers 
are  getting  better  at  recognizing  and  optimizing  the  simple  structures  that  make  up  the  bulk  of 
most  programs.  The  rest  of  the  problem  is  a  consequence  of  lack  of  control  over  time  and  storage 
utilization,  which  are  discussed  under  “Achieving  Correct  Timing”  and  “Control  over  Memory 
Usage”. 


2.14  Interactions  with  Hardware 

Ada  goes  a  long  way  toward  providing  means  for  specifying  interactions  with  hajrdware.  These 
include  representations  clauses  for  most  data  representation  dependencies,  machine-code  inserts, 
and  interrupt  entries.  However,  there  are  still  quite  a  few  hardware  dependencies  for  which  no 
specification  mechanism  is  provided. 

We  have  already  discussed  problems  in  the  realm  of  interrupts,  under  “Interaction  with  the  Real 
World”. 

In  the  real  of  representation  clauses,  there  is  no  specification  mechanism  for  array  layout,  including 
direction  and  alignment  of  elements.  There  is  no  way  of  specifying  object  alignment  (e.g.,  word, 
page,  segment).  There  is  no  standard  for  machine-code  inserts,  or  for  references  within  such  inserts 
to  entities  declared  elsewhere  in  the  Ada  progrzmi.  There  is  no  way  to  get  an  access  value  that 
designates  a  statically  allocated  interface  object,  such  as  a  buffer.  There  is  no  way  of  specifying  an 
interface  data  object,  and  no  way  of  specifying  a  separate  linker-name  for  an  interface  subprogram. 
There  is  no  way  of  specifying  a  function  in  machine-code.  Many  implementations  do  not  permit 
specifying  some  important  attributes,  especially  values  'small  attribute  for  fixed-point  types  that 
are  not  a  power  of  2.  (This  is  especially  important  because  the  input  and  output  data,  as  well  as 
the  timing  periods,  of  many  hardware  devices  are  decimal  fractions.) 
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2.15  Portability 


Ada  does  go  farther  to  help  portability  than  any  language  up  to  this  point.  Anecdotal  reports 
comparing  experience  porting  programs  in  Ada  versus  other  languages  make  Ada  look  very  good. 
This  is  due  in  large  part  to  Ada’s  provision  for  explicit  specification  of  data  representation  and 
the  precision  of  numeric  types,  type  attributes,  and  especially  the  strict  validation  and  subsetting 
policy.  It  should  therefore  not  be  criticized  too  much  for  still  having  a  few  problems. 

As  with  any  language,  Ada’s  remaining  portability  problems  are  due  to  implementation  depen¬ 
dencies  allowed  by  the  Standard.  A  few  especially  troublesome  examples  of  these  include:  a  few 
arithmetic  operations  that  require  the  standard  type  INTEGER;  differences  in  task  implementations, 
such  as  processor  scheduling  and  the  accuracy  of  of  the  real-time  clock;  unimplemented  optional 
machine-dependent  features. 


2.16  Parallel  and  Distributed  Systems 

Support  for  parallel  processing  is  one  aa’ea  where  Ada  is  very  weak.  The  tasking  model  is  fairly 
well  adapted  to  a  multiprocessor  system  with  mostly  shared  memory.  Ada  does  not  adapt  so  well 
to  more  distributed  multiprocessor  configurations,  due  to  the  need  to  support  access  to  shared 
memory  between  tasks.  Of  course,  this  can  be  virtualized,  but  the  communication  overhead  is 
high.  Similarly,  the  cost  of  rendezvous  goes  up  quickly  across  a  distributed  system.  Worse,  there 
is  no  non-blocking  alternative  to  rendezvous  for  intertask  message  passing.  There  are  some  con¬ 
ceptual  problems  with  systems  of  heterogeneous  processors,  but  these  disappear  if  the  software  is 
decomposed  into  separate  programs  on  each  machine. 

Like  all  present  conventional  programming  languages,  Ada  is  likely  to  be  made  obsolete  by  the 
machines  that  are  now  on  the  horizon.  When  it  comes  to  vector  machines,  Ada  is  probably  no 
better  than  FORTRAN.  The  overloading  does  make  it  convenient  to  define  amd  use  explicit  vector 
operations,  but  automatic  vectorization  is  likely  to  run  into  problems  with  exceptions.  By  the  time 
we  reach  large  highly-parallel  networks  of  small  processors,  and  neural  nets,  the  Ada  task  model 
is  altogether  inappropriate.  Other  problems  arise  from  several  places  where  the  Ada  standard 
specifically  rules  out  concurrent  execution,  by  stating  that  execution  takes  place  “in  some  order”. 


2.17  Defense  of  Ada 

Having  made  so  many  criticisms,  we  should  say  in  Ada’s  defense  that  one  camnot  realistically  expect 
a  stamdard  programming  lamguage  to  provide  solutions  to  all  these  problems,  since  most  of  them 
aire  peculiair  to  spedfic  applications  and  processor  atrchitectures.  Nevertheless,  real-time  application 
builders  will  need  to  be  able  to  solve  these  problems  using  Adau  The  cam,  but  not  using  ready-made 
standard  solutions.  The  best  course  may  be  for  Ada  users  to  evolve  some  stamdaxd  solutions  for 
the  most  frequently  occurring  problems,  while  recognizing  that  there  will  always  be  speciad  catses 
that  require  special  solutions. 
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Approaches  to  Using  Ada  for  Real-Time 


3.1  Living  With  the  Present  Situation 

Ada  is  currently  being  used,  with  some  success,  for  real-time  programming.  There  are  complaints, 
most  of  which  we  have  discussed.  Still,  Ada  seems  to  be  at  least  as  successful  as  other  high 
level  languages  before  it.  Where  Ada  is  not  adequate,  there  is  still  recourse  to  assembly-language 
or  machine-code  inserts.  It  appears  that  Ada  tasking  is  being  abandoned  for  most  time-critical 
applications,  being  replaced  by  more  traditional  executives.  Where  the  cost  can  be  justified,  Ada 
language  implementations  are  being  tailored  to  provide  needed  features  that  are  missing  from  the 
standard  language. 


3.2  Language  Changes 

There  is  talk  about  language  changes.  It  is  likely  that  the  ‘*Ada9x”  process  will  help  clear  up 
some  problems.  For  instance,  there  appears  to  be  strong  support  for  reintroducing  some  form 
of  asynchronous  exception  mechanism,  similar  to  the  “raise  T’failure”  feature  that  was  dropped 
during  thd  1983  language  revision.  It  is  also  likely  that  inconsistencies  within  the  present  priority 
scheme  will  be  eliminated.  However,  it  woTild  be  unwise  to  depend  on  the  language  change  process 
for  any  solutions  to  really  pressing  problems. 

Language  changes  are  not  likely  to  be  approved  until  some  time  in  the  early  1990’s  and  then  they 
will  take  more  time  to  be  Implemented.  They  are  therefore  a  long-term  solution.  Besides,  even 
if  we  could  change  Ada  and  implement  the  changes  immediately,  it  is  not  clear  what  changes  are 
needed,  or  whether  it  is  the  language  that  needs  changing  at  all. 

Many  fundamental  problems  of  real-time  software  engineering  are  still  not  well  solved.  We  can 
expect  that  new  techniques  will  be  developed  in  the  coming  yeairs.  For  example,  recent  research 
in  the  areas  of  read-time  scheduling  (c.f.,  [LNLd^SS])  has  shown  that  the  simple  static  priority- 
driven  processor  allocation  model  of  Ada  is  inadequate,  and  opened  up  a  wide  range  of  potential 
alternate  scheduling  techniques.  Based  on  what  is  known,  it  appears  that  any  small  set  of  scheduling 
techniques  we  might  choose  to  support  as  standard  options  today  are  likely  to  prove  too  limiting. 
For  this  reason,  scheduling  experts  suggest  that  Ada  should  not  specify  any  standard  scheduling 
technique,  but  should  leave  this  option  to  the  application  programmer.  Similar  uncertainty  exists 
about  some  other  hard  problems  of  real-time  systems,  such  as  distribution,  fault  tolerance,  and 
reconfiguration.  These  problems  are  still  not  well  enough  understood  to  admit  to  uniform  standard 
solutions. 

It  is  clear  that  we  cannot  expect  a  programming  language  to  provide  standard  built-in  solutions 
to  problems  we  are  still  learning  how  to  solve.  In  the  mean  time,  there  is  no  reason  we  shouldn't 
use  Ada  to  buHd  custom  solutions  to  these  problems,  just  as  we  would  assembly  language  or  any 
other  language.  The  key  issue  here  is  that  we  must  provide  an  adequate  set  of  primitives,  and  the 
freedom  to  use  these  primitives  to  design  new  solutions,  without  imposing  arbitrary  restrictions. 
This  is  the  kind  of  change  we  should  hope  to  see  in  Ada9x,  but  we  cannot  wait. 
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3.3  Implementation-Defined  Extensions 

In  the  short  term,  we  can  only  take  advantage  of  the  liberties  given  to  implementations  by  the 
existing  Ada  standard.  These  include  the" right  to  define  new  attributes,  pragmas,  and  packages. 
This  freedom  is  sufiicient  to  allow  the  extensions  we  need  to  work  around  every  shortcoming  of 
the  standard  language.  However,  the  implementation  of  some  of  these  extensions  will  need  to  be 
integrated  at  a  low  level  with  the  rest  of  the  Ada  language  implementation. 

If  there  is  sufiicient  demand,  the  Ada  compiler  vendor  may  provide  the  needed  extensions  as  part  of 
a  standard  product.  This  is  increasingly  likely  as  compiler  vendors  begin  to  write  their  own  runtime 
systems  in  Ada,  since  runtime  systems  have  many  of  the  problematic  chaxzw:teristics  of  real-time 
systems.  Other  factors  influencing  vendors  to  provide  needed  extensions  include  special  requests 
from  customers,  and  market  pressure  created  by  customer  awareness.  Publication  of  “standard” 
extensions  like  the  ARTEWG  CIFO  [CIFO]  can  contribute  to  this  market  pressure. 

As  time  goes  on,  one  would  expect  the  collection  of  extensions  to  reach  a  point  where  it  is  adequate 
to  most  users’  needs.  However,  if  a  vendor  does  not  provide  a  feature  that  is  needed,  the  user  has 
the  recourse  of  customization.  This  can  be  performed  by  the  compiler  vendor,  if  the  vendor  hats  the 
manpower  available  and  the  customer  can  afibrd  it.  Otherwise,  the  application  builder  may  need 
to  perform  this  customization. 

Of  course,  by  introducing  implementation-dependent  extensions  we  have  lost  some  of  the  benefit  of 
a  standard  language,  but  we  really  had  no  choice.  There  are  well-known  ways  to  lessen  this  blow. 
We  can  design  so  as  to  isolate  implementation  dependencies  in  a  few  modules.  We  should  certainly 
try  to  share  solutions,  so  as  to  avoid  needless  divergence,  and  for  those  areas  where  the  need  for 
extensions  is  well  accepted  we  can  establish  ancillary  standards. 


3.4  Customization  for  Specific  Hardware 

There  is  another  good  and  independent  reason  for  wanting  to  customize  an  Ada  language  imple¬ 
mentation.  This  has  to  do  with  application-specific  hardware  dependencies,  and  changes  to  these 
dependencies  during  the  life  of  the  application  system.  It  is  a  characteristic  of  real-time  systems 
that  they  typically  include  custom  or  special-purpose  hardware,  or  at  least  that  they  connect  a 
variety  of  hardware  components  in  a  configuration  specific  lo  the  application.  The  hardware  con¬ 
figuration  may  change  between  versions  of  one  application,  several  versions  of  which  may  need  to 
be  supported  simultaneously.  Any  off-the-shelf  Ada  compilation  system  could  hardly  be  expected 
to  meet  all  such  needs.  Some  customization  will  be  necessary. 


3.5  Tailoring  and  Configuration 

There  are  several  approaches  to  customization.  One,  which  we  have  already  mentioned,  is  to  pay 
the  compiler  vendor  to  do  it.  In  that  case,  the  user  need  not  be  concerned  with  how  it  is  done. 
The  chief  drawback  to  this  approach  is  the  cost,  but  there  are  many  other  reaso^.s  ♦’he  user  may 
prefer  to  do  his  own  customization.  Some  examples  of  such  reasons  include  concern  that  manpower 
problems  might  prevent  the  vendor  from  meeting  user  deadlines,  continually  evolving  requirements 
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due  to  a  prototyping  mode  of  development,  or  a  desire  to  keep  details  of  the  application  hardware 
architecture  secret. 

Few  application  developers  are  prepared  to  tackle  the  customization  of  a  complete  Ada  compilar 
tion  system.  (For  those  who  are,  there  may  be  nothing  further  to  discuss.)  On  the  other  hand, 
most  application  developers  have  some  expertise  in  building  or  customizing  executives  and  smaller 
software  tools,  such  as  linkers  and  debuggers.  Thus,  some  of  them  are  chosing  to  to  buy  source 
licenses  from  compiler  vendors  and  tackle  customization  of  small  components  of  the  compilation 
system  directly,  especially  the  RTS. 

Let  us  call  the  actual  modification  of  the  code  of  the  Ada  compilation  system  “tailoring”,  because 
it  is  analogous  to  the  kind  of  alteration  a  tailor  does  to  fit  a  ready-made  suit  to  a  customer,  which 
involves  cutting  and  stitching.  Let  us  contrast  this  with  a  less  extreme  form  of  adjustment,  which 
we  call  “configuration”  in  which  the  user  chooses  options  and  supplies  parameters  within  a  scheme 
set  up  by  the  compilation  system.  (This  is  analogous  choosing  the  best-fitting  jacket  and  and  the 
best-fitting  pants  from  two  racks  containing  different  sizes  and  styles,  or  using  a  belt  to  adjust  the 
fit  of  clothing  that  is  too  loose,  so  that  no  alteration  is  necessary.) 

Clearly,  the  division  of  a  compilation  system  into  modules  with  parameters  and  clearly  defined 
interfaces  can  assist  in  both  tailoring  and  configuration.  If  tailoring  is  required,  clean  module 
intcifaces  can  help  to  localize  changes  to  a  single  module,  and  if  an  adequate  choice  of  parameters 
or  alternate  module  versions  are  provided  customization  may  reduce  to  choosing  among  these 
options. 

Most  compiler  vendors  provide  some  combination  options  and  parameters  for  configuring  their 
compilers  and  runtime  systems,  if  only  for  their  own  convenience  in  supporting  multiple  host  and 
target  combinations.  This  is  a  good  starting  point,  and  as  time  goes  on  we  can  expect  vendors 
to  provide  mor^  such  configuration  options,  given  sufficient  pressure  from  customers.  It  is  incon¬ 
ceivable,  however,  that  any  set  of  configuration  choices  will  be  adequate  to  handle  the  needs  of  all 
applications.  Some  tailoring  (i.e.  custom  coding)  will  be  necessary. 

The  RTS  is  the  part  of  an  Ada  compilation  system  most  likely  to  need  tailoring.  This  is  good  news, 
because  it  is  much  smaller  and  simpler  than  an  Ada  compiler,  and  can  be  designed  so  as  to  be 
separated  very  cleanly  from  the  rest  of  the  compilation  system.  How  difficult  it  is  to  tailor  the  RTS 
depends  on  the  modularity  of  the  RTS  design,  the  quality  of  the  documentation  available,  and  how 
often  the  compiler  vendor  changes  key  interface  conventions.  It  can  be  a  large  and  difficult  job,  or 
very  simple. 


3.6  Alternate  Models  of  Concurrency 

One  of  the  main  reasons  for  tailoring  the  Ada  RTS  is  to  support  an  extended  or  entirely  alternate 
model  of  concurrency.  As  we  have  mentioned,  there  are  good  reasons  for  dissatisfaction  with  the 
minimal  standard  Ada  tasking  model. 

Some  real-time  system  developers  are  choosing  to  provide  their  own  executives,  which  execute 
multiple  Ada  procedures  concurrently.  This  is  permitted  by  the  Ada  standard  on  the  basis  that 
these  procedures  are  viewed  as  separate  main  programs.  This  capability  can  be  provided  alongside 
Ada  tasking.  The  Lstce  executive  [Lace]  represents  one  way  of  doing  this.  Lace  offers,  more  or 
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less,  a  stripped-down  implementation  of  Ada  tasks,  so  that  no  execution  price  is  paid  for  unused 
functionality.  If  the  implementation  of  full  Ada  tasking  is  constructed  on  top  of  Lace,  the  user 
has  the  option  of  executing  any  combination  of  Ada  procedures  as  Lace  threads  concurrently  with 
normal  Ada  tasks.  The  Lace  dispatcher  controls  the  allocation  of  the  processor  time  to  both  Lace 
threads  and  Ada  tasks. 

The  IEEE  POSDC  portable  operating  system  interface  and  and  the  IEEE  MOSI  microcomputer 
system  interface  standards  are  examples  of  other  program-based  models  of  concurrency  competing 
with  Ada  tasking.  Another  is  the  Distributed  Ada  Real-time  Kernel  (DARK),  currently  under 
development  in  the  Software  Engineering  Institute  at  Carnegie-Mellon  University. 

Examples  of  extended  task-based  models  of  concurrency  are  the  implementation  of  alternate  ren¬ 
dezvous  and  scheduling  models  based  on  priority  inheritance  at  the  Software  Engineering  Institute 
and  (independently)  by  DDC-I  compiler  vendors.  Other  tasking  extensions  that  have  been  report¬ 
edly  implemented  via  RTS  tailoring  include  non-waiting  entry  calls,  task  restarts,  and  distributed 
execution.  This  list  will  grow. 


3.7  Standard  Interfaces 

A  key  element  in  developing  extended  or  alternate  Ada  runtime  systems  (RTS’s)  depends  on  well- 
defined  interfaces.  There  are  two  main  reasons  for  having  such  interfaces.  The  first  is  to  provide 
a  means  for  the  user  (i.e.,  application  programmer)  to  communicate  with  the  extended  RTS.  The 
second  reason  is  to  permit  modifications  and  extensions  to  the  RTS  without  concern  for  the  internals 
of  the  Ada  compiler. 


Levels  of  Interface 

In  separating  these  concerns,  it  is  useful  to  distinguish  the  different  levels  at  which  such  interfaces 
are  needed: 

1.  application- RTS  -  the  interface  which  allows  a  programmer  to  invoke  RTS  services  explicitly. 
Such  a  request  would  ordinarily  be  for  a  service  not  provided  by  standard  Ada,  such  as  to 
raise  an  exception  in  some  Ada  task,  or  to  execute  some  task  periodically.  This  is.  the  level 
of  interface  at  which  the  user  can  take  control  directly. 

2.  compiler-RTS  -  the  interface  by  which  code  generated  by  the  compiler  implicitly  requests 
RTS  services,  in  order  to  implement  primitive  Ada  constructs.  Such  requests  would  include 
delaying  the  execution  of  a  task,  creating  a  new  task,  and  calling  an  entry  of  a  task.  These 
services  are  standard,  but  may  involve  implementation  choices  over  which  a  user  may  desire 
extra  control. 

The  only  constraints  imposed  on  the  RTS  implementor  by  the  Ada  language  are  at  this  level. 

3.  RTS-RTS  -  the  interface  between  RTS  modules,  by  which  different  components  of  the  RTS 
communicate  and  request  service  from  one  another.  Examples  of  such  interfaces  include  the 
mechanisms  by  which  the  tasking  RTS  can  cause  an  exception  to  be  raised  in  a  task,  and  by 
which  the  delay  implementation  obtains  information  about  the  passage  of  time. 
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Constraints  which  the  RTS  imposes  on  itself  at  this  level  can  be  helpful  in  localizing  application- 
specific  modifications  to  the  RTS.  This  level  of  interface  can  be  especially  useful  to  the  extent 
that  it  separates  functions  of  the  RTS  that  are  completely  determined  by  the  Ada  language 
from  those  whose  functions  are  only  partly  determined,  and  from  those  that  are  not  directly 
connected  with  the  language  implementation. 


4  The  ARTEWG  MRTSI 

The  Model  Runtime  System  Interface  (MRTSI)  is  a  document  describing  a  model  compiler-RTS 
interface,  and  some  elements  of  an  RTS- RTS  interface.  This  interace  isolates  the  RTS  components 
directly  concerned  with  the  implementation  of  tasking  from  compiler  and  other  key  RTS  compo¬ 
nents.  It’s  intended  purpose  is  to  “serve  as  a  model  of  clean  delineation  and  explicit  documentation 
of  the  interface  lo  an  Ada  runtime  system”,  in  hopes  that  “this  can  contribute  to  the  production  of 
Ada  runtime  systems  that  are  better  suited  to  the  needs  of  diverse  applications,  especially  real-time 
embedded  applications,  ...  provide  a  pedagogical  service  to  both  application  builders  and  compiler 
vendors  by  providing  a  baseline  and  common  frame  of  reference,  in  a  manner  similar  to  that  in 
which  theX)SI  model  serves  the  communication  community”,  and  “encourage  greater  commonality 
in  RTS  interfaces,  without  going  so  far  as  to  impose  a  formal  standard.”  [MRTSI] 


4.1  Status  of  the  MRTSI 

The  MRTSI  is  still  evolving.  It  has  gone  through  several  revisions,  starting  from  an  original  draft 
produced  in  the  summer  of  1987,  and  Version  2.3  has  been  submitted  for  publication  in  the  ACM 
SIGAda  newsletter  Ada  Letters.  All  specific  references  to  features  of  the  MRTSI  in  this  report  refer 
to  the  current  version  at  the  time  this  report  was  written,  MRTSI  Version  1.5.1. 

Input  to  the  MRTSI  has  been  provided  by  twenty-five  individuals,  with  experience  writing  Ada 
compilers,  Ada  runtime  systems,  operating  systems,  and  real-time  application  programs.  Some  of 
this  input  wa..  provided  directly,  at  meetings,  and  some  of  it  was  provided  in  the  form  of  written 
critical  reviews,  received  in  response  to  a  bros^cast  mailing  of  Version  1.4  to  known  .\da  compiler 
developers.  The  author  of  this  report  served  as  collator  of  these  reviewers’  comments,  as  well  as 
leader  of  the  MRTSI  Task  Force  within  the  ARTEWG.  and  principal  editor  of  the  MRTSI  document. 


Ideally  an  RTS  interface  specification  like  the  MRTSI  would  be  sufficiently  precise  to  permit  inter¬ 
operability  of  compilers  and  RTS  implementations;  that  is,  any  RTS  implementation  that  adheres 
to  the  interface  would  work  correctly  with  any  compiler  that  also  conforms  to  the  interface.  The 
present  MRTSI  draft  is  too  loosely  specified  to  achieve  this.  If  it  were  tightened  up  enough  to 
achieve  interoperability,  it  would  probably  need  a  specific  variant  for  each  target  processor  and 
memory  architecture. 
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Another  obstacle  to  a  tighter  interface  specification  is  the  compiler  vendors.  Most  compiler  vendors 
seem  opposed  to  the  idea  of  a  standard  RTS  interface  in  any  form,  and  their  opposition  to  even 
a  “model”  interface  seems  to  grow  in  proportion  to  its  restrictiveness.  Their  first  main  objection 
is  the  cost  of  converting  their  present  (dissimilar)  RTS  interfaces  so  that  they  conform.  Another 
objection  is  that  they  hope  to  achieve  some  market  advantage  through  proprietary  RTS  features, 
which  they  neither  wish  to  disclose  for  inclusion  in  a  standard  interface,  nor  be  obliged  to  do 
without.  Their  third  main  objection  is  that  they  simply  do  not  want  to  limit  their  future  options 
based  on  today’s  understanding  of  runtime  systems. 


4.2  Prototyping  the  MRTSI 

In  order  to  increase  our  level  of  confidence  in  the  MRTSI,  that  it  can  indeed  be  implemented 
efficiently  and  does  support  Ada  tasking  correctly,  we  constructed  and  tested  prototype  imple¬ 
mentations  of  Version  1.5.1.  This  made  heavy  use  of  code  from  an  existing  implementation  of 
Corset[Corset],  an  Ada  runtime  system  interface  designed  by  T.  P.  Baker  with  support  of  the  Boe¬ 
ing  Aerospace  Company  and  the  Boeing  Commercial  Airplane  Company.  (Development  of  the 
original  prototype  Corset  implementation  was  done  in  1987  at  the  Florida  State  University  under 
contract  t9  the  Boeing  Commercial  Airplane  Company  under  Purchase  Order  Y-429341-0957N)^. 


4.3  Differences  Between  Corset  and  the  MRTSI 

Because  Corset  and  the  MRTSI  are  functionally  similar  (like  any  two  Ada  RTS  implementations), 
it  was  not  very  difficult  to  modify  the  Corset  implementation  to  conform  to  the  MRTSI  interface 
(Version  1.5.1).  Of  course,  there  were  quite  a  few  superficial  changes,  such  as  in  names,  data  type 
declarations,  and  parameters,  but  the  only  changes  that  required  modification  of  the  functional 
code  and  internal  data  structures  of  the  prototype  RTS  were: 

1.  Rendezvoxis.  In  Corset,  the  bodies  of  accept  statements  are  compiled  as  procedures.  The 
RTS  calls  one  of  these  procedures  when  it  is  time  for  a  rendezvous  to  taJse  place.  Completion 
of  the  rendezvous  is  implicit,  through  return  to  the  RTS.  In  the  MRTSI,  accept- bodies  are 
compiled  in-line.  The  RTS  begins  a  rendezvous  by  returning  control  to  the  compiled  code, 
which  executes  the  accept-body  and  then  calls  the  RTS  again  at  the  end  of  the  rendezvous. 
This  requires  two  new  RTS  service  calls:  one  for  normal  end  of  rendezvous,  and  the  other  for 
end  of  rendezvous  due  to  an  unhandled  exception  (in  which  the  exception  is  propagated  to 
the  calling  task). 

2.  Task  elaboration  checks.  In  Corset,  the  compiler-generated  code  is  entirely  responsible  for 
checking  that  when  a  task  is  activated  the  corresponding  task  body  declaration  has  been 
elaborated  previously.  In  the  MRTSI,  this  responsibility  is  shared  by  the  RTS.* 

3.  Activation  sets.  In  Corset,  the  compiler-generated  code  is  entirely  responsible  for  keeping 
track  of  sets  of  tasks  that  are  to  be  activated  together.  A  set  of  tasks  that  are  to  be  activated 

‘The  Ada  code  of  the  modified  Prototype  Corset  Implementation  Software,  as  reported  here,  is  copjrrighted  by 
T.P.  Baker  and  the  Florida  State  University,  and  is  releaa^  subject  to  specific  provisions  included  in  the  distribution 
tape.  A  copy  of  a  tape  containing  this  this  Software  was  delivered  to  the  U.S.  Army  CECOM  with  this  report. 

^Contrary  to  this  author’s  preference  for  cleaner  separation  of  functions. 
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together  is  passed  to  the  RTS  via  a  parameter  of  an  unconstrained  array  type.  By  contrast, 
the  MRTSI  reqmres  the  RTS  and  the  compiler-generated  code  to  cooperate  more  closely.*  A 
set  of  tasks  that  are  to  be  activated  together  is  identified  by  the  ID  of  the  last-created  member 
of  the  set.  When  a  task  is  created,  the  compiler-generated  code  specifies  the  activation-set  to 
which  it  should  be  appended,  via  the  ID  of  the  last-created  member  of  that  set.  When  a  set 
of  tasks  is  to  be  activated,  the  set  is  specified  likewise. 

4.  Special  cases.  The  MRTSI  goes  beyond  Corset  in  distinguishing  special  cases  of  “trivial” 
rendezvous.  Implementing  these  required  new  code. 

4.4  A  Problem  with  Visibility 

We  discovered  that  the  way  in  which  the  MRTSI  is  divided  into  several  packages  limits  visibility 
of  key  declarations  in  a  way  that  makes  implementation  difficult.  The  problem  is  that  the  bodies 
of  the  RTS  implementation  packages  need  to  share  access  to  information  that  the  MRTSI  tries 
to  hide  from  the  compiler.  This  information  is  in  declarations  belonging  to  the  bodies  and  the 
private  parts  of  the  severail  MRTSI  packages.  For  example,  the  type  TASK.ID  exported  by  package 
RTS_TASK_IDS  is  private,  and  should  be  so  from  the  viewpoint  of  compiler-generated  code,  but  the 
RTS  impletnentation  packages  need  a  way  to  associate  attributes  with  task  IDs.  While  this  could 
theoretically  be  done  using  table  lookup,  that  would  exact  an  unacceptable  cost  in  execution  time. 
In  our  prototype,  we  therefore  made  the  full  declaration  of  type  TASK.  ID  visible. 

A  more  difficult  problem  is  how  to  initialize  data  structures  that  belong  to  package  RTS.RENDEZVOUS 
when  a  new  task  is  created  by  procedure  CREATE.TASK,  in  package  RTS  .STAGES.  We  know  of  only  two 
ways  to  solve  this  kind  of  problem.  One  is  to  add  a  new  operation,  that  is  not  part  of  the  MRTSI, 
to  package  RTS  .RENDEZVOUS.  The  other  is  to  put  such  extra  operations  in  a  hidden  “twin”  package, 
say  RTS.RENDEZVOUS. IMPLEMENTATION,  which  would  also  contain  duplicates  of  all  the  declarations 
in  RTS.RENDEZVOUS.  The  operations  exported  by  RTS.RENDEZVOUS  would  then  be  implemented  by 
operations  of  RTS. RENDEZVOUS. IMPLEMENTATION,  using  UNCHECKED. CONVERSION  to  circumvent  any 
type  incompatibilities  introduced  by  the  duplicate  declarations. 

Creating  twins  for  the  MRTSI  packages,  as  in  the  example  above,  can  preserve  the  purity  of  the 
MRTSI  package  specifications  at  the  expense  of  very  ugly  code  in  the  package  bodies  and  their  twins. 
Moreover,  at  the  present  state  of  Ada  compiler  development,  this  solution  is  almost  certain  to  result 
in  unacceptable  execution-time  overhead,  due  to  extra  layers  of  procedure  calls.  We  therefore  chose 
to  add  what  declarations  we  needed  to  the  MRTSI  packages,  and  to  convert  some  private  t3rpe 
declarations  into  RTS-implementation  dependent  full  type  declarations.  (See  Appendix  A  for  the 
expanded  package  specifications  as  used  in  the  prototype.) 


4.5  Testing  the  MRTSI  Prototype 

Converting  the  test  programs  developed  for  Corset  to  conform  to  the  MRTSI  was  more  time- 
consuming  than  converting  the  RTS  implementation.  Because  there  is  no  Ada  compiler  that  com¬ 
plies  with  the  Corset  (or  the  MRTSI)  interface,  the  test  programs  were  originally  hand-translated 
from  programs  written  in  full  Ada  (including  tasking).  This  hand  translation  had  to  be  redone  to 
conform  to  the  MRTSI. 
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Because  we  wanted  this  prototype  to  be  portable,  the  test  programs  are  translated  into  a  simple 
subset  of  Ada  (without  tcisking).  They  make  explicit  calls  to  the  RTS  to  perform  tasking  operations 
where  an  Ada  compiler  would  insert  such  calls  implicitly  when  translating  Ada  tasking  constructs. 
Further,  because  we  needed  to  be  able  to  simulate  concurrency  (both  between  tasks  and  between 
multiple  processors)  and  other  effects  that  normally  would  be  achieved  by  machine- dependent  and 
compiler-dependent  code,  the  translation  is  rather  complex.  All  procedures,  task  bodies,  and  accept 
statement  bodies  are  converted  to  blocks  of  code  in  a  single  massive  case  statement;  all  variables 
and  parameters  are  converted  to  components  of  a  massive  variant  record  type;  lexical  nesting  effects 
are  simulated  via  explicit  chaining  of  these  activation-records. 

An  example  of  the  translation  is  sketched  below.  Two  complete  examples  are  given  in  Appendix  B. 


package  PKG  is 

task  T  is  entry  E;  end  T; 
end  PKG; 

eith  TEXT.IO;  use  TEXT_I0; 
package  body  PKG  is 
task  body  T  is 

begin  accept  £  do  PUT.LINEC'in  rendezvous  on  E"};  end  E; 
end  T;  ' 
end  PKG; 

with  PKG;  use  PKG; 

procedure  test  is  begin  T.E;  end  test; 


This  is  translated  into  following  code  for  the  main  program  and  body  of  task  T: 


NAIH:  constant  PROCEOROE:*  2; 
T_PR0C:  constant  PROCEORUE:"  5; 
ACC.E.PROC:  constant  PROCEDROE:"  6; 


begin  case  P  is 

eben  MAIN-> 

—  task  T; 

RTS.STXGES . CREATE.TASK ( 

SIZE->  RTS.STAGES.SIZE.TTfPECDA'size/STORAGE.UHIT) , 
PRI0->  1, 

>U11_EHTRIES">  1, 

MASTER->  RT3.3TAGES.CURREirr_HASTER, 

STATE->  (T_PR0C .COERCE(DA) .MOLL.DATA.AKEA) , 
UST_CREATED->  HDLL.TASK, 

ELABORATED->  ELABORATED, 

CREATED_TASK->  DA.T); 

RTS.STAGES . COMPLETE.ACTIVATIOM ; 
RTS.STAGES.ACTIVATE,TASKS(DA.T) ; 

—  T.E; 

RTS .RENDEZVOUS . C ALL.SIMPLE ( ACCEPTOR->DA . T . 

E->  1, 

PARAMETER-XIULL.DATA.AREA.O)  ) ; 

RTS.STAGES . COMPLETE.TASK ; 

•hen  T_PROC“> 

RTS.STAGES . COMPLETE. ACTIVATIOI ; 
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—  accept  E  do 

RTS_REiroEZVOUS,ACCEPT_CJaL(E->  1, 

PARilMETER->  Dl.PARiWETER) ; 

begin  CHECK (2) ; 

RTS_REHDEZVOUS .  COHPLETE.RENOEZVOtlS ; 
exception 

when  otbers-»  RTS.REHDEZVOUS.EXCEPTZOHAL.COHPLETE.REHDEZVaUS 
(RTS_EXCEPTIOHS.CORREirr_EXCEPnON)  ; 

end; 

RTS_STAGES . COMPLETE.TASK ; 
when  ACC_E_PR0C-> 

PQT_LIHE("in  rendezvous  on  E") ; 

end  case; 


Each  executable  program  unit  corresponds  to  one  alternative  of  the  case  statement,  which  is  indexed 
by  a  parameter  P  of  type  PROCEDRUE.  The  variable  DA  points  to  a  local  data  area  which  has 
been  allocated  for  the  program  unit  that  is  executing.  All  the  standard  Ada  task  structures  have 
been  replaced  by  explicit  MRTSI  calls,  such  as  would  be  generated  in  a  translation  of  the  program 
by  a  compiler  that  conforms  to  the  MRTSI  interface.  The  executions  of  the  two  programs  should 
therefore  be  the  same,  up  to  allowed  implementation-dependencies  such  as  the  task  dispatching 
policy. 

Some  effort  was  made  to  produce  a  program  to  perform  this  translation  of  test  programs.  Such  a 
translation  tool  would  have  allowed  us  to  generate  test  programs  quickly  for  various  RTS  interfaces 
from  any  test  program  written  in  standard  Ada.  Specifically,  we  investigated  the  feasibility  ci 
modifying  the  FSU/AFATL  Ada  compiler  for  this  purpose.  This  compiler  was  designed  t  ■>  translate 
from  Ada  to  Z8002  assembly  code.  For  a  moderate  investment  of  efifort  (as  compared  with  writing 
such  a  translator  from  scratch),  it  should  be  possible  to  convert  this  compiler  to  output  simple 
(non-tasking)  Ada  code  instead  of  Z8002  assembly  code,  with  the  necessary  calls  to  the  MRTSI 
for  tasking  operations.  Nevertheless,  it  looked  as  if  two  man-months  or  more  would  be  required  to 
complete  such  a  program,  so  we  were  forced  to  be  satisfied  with  limited  hand-translation. 

Because  converting  test  programs  to  the  MRTSI  interface  by  hand  was  so  labor-intensive,  only  a 
few  were  converted.  However,  those  that  were  converted  all  worked  correctly  without  detecting  any 
bugs  in  the  MRTSI  implementation,  beyond  typos  of  the  most  trivial  kind.  This  was  expected, 
since  the  difierences  between  the  Corset  and  MRTSI  prototypes  were  superficial;  i.e.,  limited  to  the 
interface.  After  all,  any  two  Ada  RTS  implementations  should  be  semantically  equivalent,  so  far 
as  can  b  detected  by  a  correct  Ada  program. 


4.6  Lessons  Learned  from  Testing 

The  information  gained  about  the  MRTSI  was  mostly  positive.  It  apparently  works  as  intended. 
Some  simple  syntax  problems  were  discovered  in  the  package  specifications,  but  these  were  easily 
corrected.  Conversion  of  our  RTS  implementation  to  the  MRTSI  was  not  difficult. 

On  the  negative  side,  we  discovered  two  things  of  a  subjective  nature  about  the  MRTSI,  which  will 
be  reported  to  the  ARTEWG  MRTSI  Task  Force: 
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1.  performing  elaboration  checks  for  task  bodies  adds  considerable  overhead  to  task  creation 
and  activation,  that  mnst  be  paid  even  in  cases  where  it  can  be  verified  at  compile  that  no 
elaboration  check  is  needed.  This  is  sad  because  cases  were  runtime  elaboration  checks  for 
tasks  are  needed  appear  to  be  unusual. 

2.  Supporting  an  efficient  implementation  of  the  “trivial”  cases  of  rendezvous  appeared  to  require 
adding  some  overhead  to  the  normal  cases. 

5  Conclusions 


After  some  early  developmental  difficulties,  Ada  seems  to  be  maturing  into  a  language  that  can 
be  used  for  real-time  software.  However,  the  minimum  features  required  by  the  Ada  standard  are 
insufficient.  Producing  effective  real-time  systems  requires  extended  features  that  may  be  legally 
provided  by  an  Ada  language  implementation  within  the  constraints  of  the  Ada  standard. 

Since  solutions  to  most  of  the  shortcomings  presently  perceived  in  Ada  as  a  real-time  language  can 
be  solved  within  the  latitude  permitted  language  implementations,  it  is  convenient  to  view  these  as 
shortcomings  of  implementations  rather  than  of  the  language.  We  thus  sidestep  the  organizational 
difficulties  and  delays  required  for  language  changes,  as  well  as  the  more  serious  difficulties  of 
anticipating  the  results  of  ongoing  research  in  real-time  systems  and  the  special  needs  of  future 
real-time  applications. 

In  the  longer  run,  it  appears  desirable  to  work  toward  standardization  of  extensions  which  have  been 
implemented,  tested,  and  found  to  meet  requirements  of  a  large  class  of  applications,  and  which 
are  not  yet  satisfied  by  other  standard  mechanisms.  In  a  few  cases  the  standardization  vehicle 
might  be  the  Ada  language,  but  in  others  cases  separate  ancillary  standards  may  be  better.  Such 
an  ancillary  standard  could  define  a  collection  of  runtime- system  packages  with  logically  related 
functions,  analogous  to  the  CAIS[CAIS]. 

We  hope  that  a  good  place  to  begin  to  define  such  ancillary  standards  is  with  a  compUer-RTS 
interface  specification,  and  in  particular  the  MRTSI.  If  such  a  standard  were  even  adopted  by  even 
a  few  compiler  vendors  it  could  give  more  impetus  to  the  development  of  specialized  Ada  runtime 
environments. 

The  MRTSI  appears  to  be  converging  to  a  form  that  will  be  acceptable  to  both  the  ARTEWG 
members  and  some  Ada  compiler  developers.  Based  on  the  experiments  we  performed,  it  seems 
readily  implementable.  It  may  be  sufficiently  dose  to  some  existing  Ada  implementations  that  they 
could  be  converted  to  adhere  to  it  rather  easily.  However,  most  compiler  vendors  seem  to  oppose 
any  form  of  compiler- RTS  interface  standard. 

The  present  MRTSI  draft  is  too  loosely  specified  to  support  interoperability  of  compilers  and  RTS 
implementations.  If  it  were  tightened  up  enough  to  achieve  interoperability,  it  would  probably 
need  a  specific  variant  for  each  taurget  processor  and  memory  architecture.  This  may  eventuadly 
be  possible.  In  the  mean  time,  the  MRTSI  wiH  be  useful  as  a  reference  model,  guideline  for  inter¬ 
face  separation,  and  basis  for  discussion  of  RTS’s  between  compiler  producers  and  users  requiring 
tailoring. 
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There  may  be  more  hope  for  standardization  of  other  RTS  interfaces.  One  example  would  be 
a  standard  application-RTS  interface  for  low-level  tasking  operations.  If  such  a  package  were 
available  it  might  be  used  by  application  programmers  to  implement  their  own  scheduling  policies. 
This  kind  of  interface  might  be  more  directly  useful  to  real-time  application  programmers  than  is 
the  MRTSI.  A  standaird  interface  wotdd  also  be  practical  at  the  RTS-RTS  level,  between  certain 
key  RTS  functions  which  require  user  tailoring  and  the  rest  of  the  RTS.  RTS  functions  that  might 
be  isolated  in  this  way  include  task  scheduling,  dynamic  storage  allocation,  and  real-time  clock 
services,  and  interrupt  handling. 
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A  MRTSI  Prototype  Specifications 


The  following  are  the  package  specihcations  of  the  MRTSI,  aa  modified  to  include  declarations 
needed  by  the  bodies  (i.e.,  implementations)  of  the  other  MRTSI  packages^ 


packag«  RTS.TASK.IDS  la 

typ*  TASK.IS  is  ~  dslinsd  by  RTS  iaplesantation 

raags  0..31;  — >  for  prototypa  RTS  iaplaaentation 

HOLL.TASX:  constant  TASK.ID:*  —  dslinsd  by  RTS  isplenentation 

0;  —  lor  prototypa  RTS  inplenentation 

limction  SANE_TASK(L.R:  TASX.ID)  ratum  BOOLEAH  renames 

- end  ol  MRTSI  riaw - — - - 

subtype  NOHHULL.TASX.ID  is  TASX.ID  range  1..31: 
end  RTS.TASX.IDS; 

package  RTS_EXCEPTIONS  is 

type  EXCEPTTOI.ID  is  private; 
type  EVEHT.ID  is  private; 

HULL.EXCEPTiaX.ID:  constant  EXCEPTIOl.ID; 

CQ8STRAIirr.ERR0R.ID:  constant  EZCEPTI08_ID ; 

8DMERIC.ERR0R_ID:  constant  EXCEPTIOl.ID: 

PRaGRAN.ERRaR_ID:  constant  EXCEPTIOl.ID; 

STORAGE.ERROR.ID:  constant  EXCEPTIOl.ID; 

TASXI80_ERRaR.ID:  constant  EXCEPTIOH.ID ; 
procedure  RAISE.EXCEPn08(E:  EXCEPTIOB.ID) ; 
function  CURREBTJEXCEPTIOI  return  EXCEPTIOH.ID; 
procedure  HOTIFY.EXCEPTIOI(ETEHT:  EVEHT.ID) ; 

— — — end  ol  MRTSI  view-  -  — — -- 

private  —depends  on  conpiler  and  nachine. 
type  EXCEPTIOH.ID  is  ne«  IHTEGER: 
type  EVEHT.ID  is  range  0..31; 

HULL.EXCEPTIOH_ID:  constant  EXCEPTIOH. ID : «  0; 

CQHSTRAIHT.ERROR.ID:  constant  EXCEPTIOH.ID:-  1; 

HOMERIC.ERROR.ID:  constant  EXCEPTIOH.ir 2; 

PROGRAM_ERROR_ID:  constant  EXCEPTIOH.ID:-  3; 

STORAGE.ERROR.ID:  constant  EXCEPTIOH.ID:-  4; 

TASXIHG_ERROR.ID:  constant  EXCEPTIOH.ID:-  5; 
end  RTS.EXCEPTIOHS; 

vith  SYSTEM; 

vitb  RTS.EXCEPTIOHS;  use  RTSJEXCEPTIOHS: 
vith  RTS.TASX.IDS;  use  RTS.TASX.IDS: 
vith  RTS.IHTERRIJPTS ;  use  RTS.IHTERRUPTS ; 
vith  MACHIHE;  —  only  lor  inplenentation  viev 
package  RTS.REHDEZVODS  is 
HDLL.EHTRY:  constant:-  0; 

MAX.EHTRT:  constant:-  —  value  defined  by  RTS  ijq>leaentation 

2S5;  —  lor  prototype  RTS  inplenentation 
type  EHTRT.IHDEX  is  range  MDLL.EHTRY  . .  MAX.EXTRT ; 
type  CALLER.PARAMETER_DESCRIPTOR  is  —  nachine-specilic 

record  LOC:  MACHIHE. DATA. AREA;  —  lor  prototype  RTS  inplenentation 

LEH:  HATURAL; 
and  record; 

type  ACCEPTaR_PARAMETER.DESCRIPTOR  is  —  nachine-specilic 

^Theae  package  spediications  are  copyrighted  by  the  T.P.  Baker  and  the  Florida  State  University,  and  now  are 
released  to  the  public  domain. 
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record  LOC:  HACHIIiE.DATA.AREA;  —  lor  prototype  RTS  lopleBentation 
end  record; 

—  Lover  index  bound  is  1  by  convention, 
procedure  CALL.SDIPLE (ACCEPTOR:  TASX.ZD; 

E:  EHTRY.IIDEX; 

PARAMETER;  CALLER.PARAMETER.DESCRIPTOR) ; 
procedure  CALL.CONDITIQNAL (ACCEPTOR:  TASK.ID: 

E:  EHTRT.ISDEX; 

PARAMETER:  CALLER.PARAMETER.DESCRIPTOR; 
REHDEZTOUS.StrCCESSFOL:  out  BOOLEAN); 
procedure  CALL.TIMED (ACCEPTOR:  TASK.ID; 

E:  ENTRr. INDEX; 

PARAMETER:  CALLERJ>ARAMETER.DESCRIPTOR; 

D:  DURATION; 

RENDEZVOUS .SUCCESSFUL:  out  BOOLEAN); 
procedure  TRIVIAL.CALL(ACCEPTOR;  TASK.ID; 

E:  ENTRY.INDEX; 

REBDEZTOUS.SUCCESSFUL:  out  BOOLEAN); 
type  SELECT.INDEZ  is  nev  INTEGER; 

NO.RENDEZVOUS:  constant  SELECT.INDEZ 0; 

type  ENTRY.LIST  is  array  (SELECT.INDEZ  range  <»  ol  ENTRY.INDEX; 
type  MODES  is  (SIMPLE.MODI,  DELAY.MODE,  ELSE.M0DE»  TERMINATE.HODE) ; 
procedure  SELECTIVE.WAIT(0PEN.ENTR1ES;  ENTRY.LIST; 

,  D:  DURATION; 

SELECT.MODE:  MODES; 

PARAMETER;  out  ACCEPTQR.PARAMETER.DESCRIPTOR; 
INDEX:  out  SELECT.INDEZ); 
procedure  ACCEPT.CALL(E:  ENTRY.INDEX: 

PARAMETER;  out  ACCEPTOR.PARAMETER.DESCRIPTOR) ; 
procedure  TRIVIAL. ACCEPT (E:  ENTRY.IHOEX) ; 
lunction  caOMT(T:  TASK.ID;  E:  ENTRr.INDEX)  return  NATURAL; 
function  CALLABLE (T:  TASK.ID)  return  BOOLEAN; 
procedure  ASSOClATE.IHTERRUPTdNTERRDPT:  INTERRUPT.ID; 

ACCEPTOR:  TASK.ID; 

E:  ERTRY.INDEX) ; 

procedure  DISSOCIATE.INTERRUPTdNTERROPT:  INTERRUPT.ID) ; 
procedure  COMPLETE.REHDEZVOUS ; 

procedure  EXCEPTIORAL.COMPl£TE.RENOEZVOUS(E:  EXCEPTION.ID) ; 
package  INTERRUPT.BUFFERS  is 

type  BUFFER.ARRAT  is  array  (INTEGER  range  <»  ol  INTEGER; 
type  BUFFER.ACCESS  is  access  BUFFER.ARRAY; 
type  COLLECTION.ID  is  private; 
lunction  NEV.COLLECTION (ACCEPTOR:  TASK.ID; 

E:  ENTRY.INOEZ; 

NUMBER:  POSITIVE; 

SIZE:  POSITIVE)  return  COLLECTION.ID; 
lunction  NEU.BUFFER( COLLECTION:  COLLECTION.ID)  return  BUFFER.ACCESS; 
procedure  ENQUEUE (BUFFER:  BUFFER.ACCESS); 
private 

type  COLLECTIOR.ID  is  nev  INTEGER; 
end  INTERRDPT.BUFFERS: 

- — - — ciui  ol  MRTSI  view— * — - - — — 

lunction  CALLING .TASK  return  TASK.ID; 
procedure  aPEN.ENTRIES(T:  TASK.ID;  NUM.ENTRIES:  INTEGER); 
procedure  CLOSE.ERTRIES(T:  TASK.ID); 
procedure  CALL.OFFLIHE(A:  TASK.ID; 

E:  ERTRY.INDEX; 

LOC:  MACHINE. DATA. AREA); 
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•nd  &TS.REHDEZVOUS: 


with  RTS.TASX_ZDS;  aa«  RTS.TASK.IDS ; 

■ith  NACHIHE:  lor  this  prototype  ispleHentation 

package  RTS.STAQES  is 
type  NASTER.ID  is  private; 
type  ACCESS_BOOLEAH  is  access  BOOLEAH; 

Innction  cnRREHT.NASTER  return  NASTER.ID; 

procedure  ENTER JIASTER; 

procedure  COMPLETE_HASTER; 

type  IIIT.STATE  is  —  nachine-specilic 

new  MACHINE. STATE;  —  lor  this  prototype  RTS  inplenentation 
type  SIZE.TTFE  is  —  nachine-specilic 

range  0..1023;  —  lor  this  prototype  RTS  inplenentation 

tJNSPECIFIED.SIZE:  constant  SIZE.TTPE:-  SIZE.TYPE’lirst; 
procedure  CREATE_TASX(SIZE:  SIZE.TTPE; 

PRIO:  INTEGER; 

RDM_ENTRIES:  NATURAL; 

MASTER:  NASTER.ID; 

STATE:  INIT.STATE: 

UST.CREATED:  TASK.ID; 

ELABORATED:  ACCESS .BOOLEAN; 

CREATED.TASK:  out  TASK.ID); 
procedUTf  ACTITATE.TASKS(LAST.CREATED:  TASK.ID); 
procedure  COMPLETE JICTIVATION ; 
procedure  CQMPLETE_TASK ; 

Itmction  TERMINATED (T:  TASK.ID)  return  BOOLEAN; 
lunction  IS.LOCAL.TASK(T:  TASK.ID; 

MASTER:  NASTER.ID)  return  BOOLEAN; 

- ^  ol  MRTSl  view- - - 

lunction  ANCESTORCT:  TASK.ID:  LEVEU.OUT:  INTEGER)  return  TASK.ID; 

—  used  in  abortion, 
procedure  COMPLETE (T:  TASK.ID); 

—  used  in  abortion, 
procedure  TERMINATE. ALTERNATIVE: 

—  used  in  rendezvous, 
private 

type  MASTER.ID  is  —  delined  by  the  RTS  inplaentation 
new  INTEGER; 

end  RTS.STAGES; 

package  RTS.CLOCX  is 

type  DATS  is  range  0..  (2*«31)-1: 

subtype  DAT.DDRATION  is  DURATION  range  0.0  ..  86.400.0; 

—  These  ranges  are  only  ezanples. 
type  TIME  is 

record  DAT:  DATS; 

SECOND:  DAT.DURATION; 
end  record; 

—  TICK:  constant:*  2.0*e(-14); 

—  This  value  ol  TICK  is  only  an  ezanple. 
lunction  CLOCK  return  TIME: 

———end  ol  MRTSl  wiew— — — — — — 

--TICKS.PER.SECOND;  constant:*  2e*14; 

TICKS.PER.SECOND:  constant;*  2; 

--TICK  set  large,  lor  prototype  RTS  inplenentation. 

TICK:  constant:*  l.O/TICXSJ’ER.SECOND; 
type  TICKS  is  private; 
lunction  CLOCK  return  TICKS; 
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Imction  CLOCK_IS_PAST(T:  TICKS)  return  BOOLEAM; 
l\mction  "+"(L:  TICKS;  R:  IHTEGER)  return  TICKS; 
procedure  STOP;  —  shuts  down  sisulation. 
procedure  IHTERROPT;  —  simulates  clock  tick, 
private 

type  TICKS  is  range  -(2**31) . . (2**31-1) ; 
end  RTS.CLOCK; 

with  RTS.CLOCK;  use  RTS.CLOCK; 

with  RTS.TASK.IDS;  use  RTS_TASK_IDS ;  ~  only  <or  iaplenentation  view 
package  RTS.DELAYS  is 

procedure  DELAY.SELFCO:  DURATIOH) ; 

- end  of  MRTSI  view— - 

procedure  IHTERHAL_DELAY_SELF(D:  DURATION); 

TIIlE_QF_HEXr  .CHECK:  RTS  .CLOCK.  TICKS; 
procedure  CHECK; 

procedure  CLAIM.RIGHT.TO.CAHCEL.DELAY(T:  TASK.ID;  TAKEN:  out  BOOLEAN); 
procedure  OPEN.OELAYS(T:  TASK.ID); 
procedure  CLOSE.DELAYS(T:  TASK.ID); 
end  RTS.DELAYS; 

with  SYSTEM; 

with  MACHINE;  —  for  i^lenentation  view  only 
package  RTS^STORAGE.HANAGEMENT  is 
type  COLLECnON.ID  is  private; 

function  NEH.COLLECTIONCCOLLECTION.SIZE:  NATURAL :-0; 

NA1.BL0CK.SI2E:  NATURAL: -0) 
return  CQLLECnON.ID; 

—  function  NEW.BLOCKCSIZE:  NATURAL; 

COLLECTION:  COLLECTION.ID) 
return  SYSTEM. ADDRESS; 

—  procedure  RELEASE.BLOCK (LOCATION:  SYSTEM.ADDRESS) ; 
function  NEtf.BLOCK(SIZE:  NATURAL; 

COUECnON:  COLLECTION.ID)  return  MACHINE. OATA.AREA; 
procedure  RELEASE.BLOCK (LOCATION:  MACHINE. DATA. AREA) ; 
procedure  RELEASE.COLLECTIOR (COLLECTION:  COLLECTION.ID); 

— - end  of  MRTSI  view~ — - - — - - — — 

NULL.COLLECnON:  constant  COLIECTIOH.IO: 
private 

type  COLLECTION.ID  is  range  0. . (2««1S)-1; 

NOLL.COLLECTIOR :  constant  COLLECTION.ID :■  0; 
end  RTS.STORAGE.HAHAGEMEHT; 

with  RTS.TASK.IOS;  use  RTS.TASK.IDS ; 

with  MACHINE;  —  for  prototype  RTS  iiq>leBentatioa 

package  RTS.ABORTION  is 

type  TASK.LIST  is  array  (POSITIVE  range  <>)  of  TASK.ID; 
procedure  ABORT.TASKS (TASKS:  TASK JJST) ; 

. — ——end  of  MRTSI  view— — — - — — — - 

procedure  CLAIH.RIGRT.TO.RELEASE(T:  TASK.ID; 

TAKEN:  out  BOOLEAN); 

procedure  FORESTALL. ABORTION ; 
procedure  SAFE.RELEASE(T:  TASK.ID); 
procedure  SAFE.HrLO; 
procedure  SAFE.FOaCE.CALL(T:  TASK.ID; 

P:  MACHINE. PRDCEDRUE); 
procedure  OPEN.ABORTION(T:  TASK.ID); 
end  RTS. ABORTION; 
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with  SYSTQl; 

vlth  RTS_T1SX.IDS:  usa  RTS.TASX.IDS ; 
package  RT^.mERRUPTS  is 

t^rpa  IRTERRUPT.ID  is  —  aachina-spacific 

range  0..2S5:  —  lor  this  prototype  RTS  iapleaantation 

procedure  BlBD.HAIDLER(lHTERRDPT:IHTERRaPT_ZO:  RAHDLER:  SYSTEM. ADDRESS) ; 
procedure  DRBZHD.HAIOLERCIllTERRDPTcIBTERROPT.ZD) ; 
function  IDLL_RAIDLER  return  SYSTEM. ADDRESS; 
procedure  SQFTVARE.IHTERRDPTCIHTERROPT:  IBTERRUPT.ID) ; 
procedure  ATTEMPT.PREEMPTIOH ; 
end  RTS.IRTERRUPTS; 

package  RTE_PRI0RIT1ES  is 
NI]l_PRIORITY :  constant  1; 

MAX.PRIORITY :  constant:"  31; 
end  RTE.PRI0RIT1ES; 


sith  RTS.HITERHDPTS ;  use  RTS.IHTERROPTS ; 
with  RTS.REHDEZVOOS;  use  RTSJtEHDEZTOnS ; 
sith  RTS_TASK_IDS;  use  RTS.TASX.IDS; 
package  QDEDED.IITERROPTS  is 
procedure  ASSOCIATE.ISTERRI]PT(I)nERRDPT:  ZHTERRDPT.ID; 

ACCEPTOR:  TASX.ID; 

E:  EITRY.IXDEZ} ; 

procedure  DISSOCZATE.IIITERRUPT  (IHTERROPT :  UTERRDPT.ID)  ; 
end  qUEOEO.inERRDPTS; 


B  Example 


(Test  Programs 


The  following  are  tw^  versions  each  of  test  programs.  Each  program  is  shown  before  and  after  trans¬ 
lation  to  the  form  r^uired  by  the  MRTSI  prototype.  Calls  to  procedures  CHECK ()  and  COMPLETE, 
from  package  CHECX|,  are  to  check  that  the  various  operations  are  performed  in  the  correct  order. 


—  test.l:  tests  creation  and  nomal  teraination  ol  a  collection  ol 

—  dependent  tasks. 


sith  SYSTEM; 
package  PXO.l  is 
task  T1  is 
pragu  PRIORTTYd) ; 
end  Tl; 

task  type  TTPE2  is 
pragna  PRIORITY (2) ; 
end  TYPE2; 
procedure  P; 
end  PXQ.l; 


sith  CHECXS;  use  CHECXS; 
sith  TEZT.IO; 
sith  TRACE. 1; 

pragna  ELABORATE (TRACE. 1) ; 
package  body  PXQ.l  is 
Z:  UTEOER:-  1; 
task  body  Tl  is 
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begin  CHECK (1) ; 

P; 

CHECK (2); 

CQHPI£TE; 

•Bd  Tl; 

task  body  TYFE2  is 
begin  CHECK (3) ; 

if  Z<*1  then  P;  end  if 

CHECK (4); 

CQMPIXTE; 
end  TYPE2: 
procedure  P  is 
T2:  TTPE2; 

type  accT  is  access  'nPE2; 
begin  CHECK(5) ; 

B :  declare 

task  T3  is 

pragna  PRIORITY (3) ; 
end  T3: 

task  body  T3  is 
procedure  R  is 
X:  accT; 
procedure  S  is 
T4:  TyPE2; 
begin  CHECK (6); 

X:>ne«  TYPE2: 
CHECK (7) ; 

end  S; 

begin  CHECK(8) ; 

S; 

CBECK(d) ; 

end  R; 

begin  CHECK (10); 

R; 

CHECK(ll); 

COMPLETE; 
end  T3; 

begin  CHECX(12}; 
end  B; 

CHECK (13) ; 
end  P; 
end  PKG.l; 

with  SYSTEM; 

with  <^CKS;  use  CHECKS; 
with  PKQ.l;  use  PKG.l; 
procedure  test.l  is 
pragna  PRIORITY (0) ; 
begin  CHECK (14);  COMPLETE; 
end  test.l; 


--  t<st_l:  tests  nozmal  task  tsraination. 

—  This  was  also  ussiul  in  checking  treataant  of  recovery  from  running  out 

—  of  threads,  before  range  of  threads  was  extended. 


with  RTS.ABORTION; 

with  LiCE; 

with  RIGHTS; 

with  RTS.STAGES; 

with  STORAGE: 

with  RTS.TASK.IDS; 

with  niCHECXED.DEALLOCATIOH; 

with  OHCHECXED.COHVERSIOH; 

with  TRACE.!; 

pragaa  ELABORATECTRACE.l) ; 
separate (MACHIHE) 
package  body  PROCEDROES  is 

use  LACE; 

use  MACHIHE : 

use  RTS.TASK_IOS: 

subtype  RIGHT  is  RIGHTS. RIGHT; 

procedure  CLAIM (Rt  RIGHT;  B:  out  BQOLEAH)  renaaes  RIGHTS. CLAIM; 

procedure  IIITCR:  in  out  RIGHT; 

AVAILABLE:  BOOLEAH:-  TREE}  renaaes  RIGHTS. IHIT; 

RIGHT.TO.START.OP;  RIGHT; 

—  Procedures  (siaulated). 

— ■OLL.PROCEDROE:  constant  PROCEDROE:*  0; 

—STARTUP:  constant  PROCEOHUE:*  1; 

MAIH:  constant  PROCEDROE:*  2; 

— TEBNIIATE_PROC:  constant  PROCEDRUE:*  3; 

— TASXIHG_ERRaRJ>RaC:  constant  PROCEDRUE:-  4; 

P_PR0C:  constant  PROCEDRUE:*  5; 

T1_PR0C:  constant  PROCEDRUE:*  6; 

Type2.FRaC:  constant  PROCEDRUE:*  7; 

T3.PR0C:  constant  PROCEDRUE:*  8; 

R. PR0C:  constant  PROCEDRUE:*  9; 

S. PR0C:  constant  PR0CEDRUE:*10; 

IS.TASK :  PROCEDRDE_BIT_ VECTOR:  *ADA_HAS.SIUT.RESTRIcnOHS  ( 

(MAII|TlJ'R0C|Type2_PR0C|T3_PR0(»  TRUE, 
others*>  FALSE) ); 

LEVEL:  PROCEOROE_IRTEGER.VECTOR:*AOA_HAS.SILLT_RESTRICTIOHS( 

(HDLLJ>ROCEDROE*>  -1, 

STABTDP*>  0, 

HAII*>  !, 

TERMI1ATEJ>R0C*>  2, 

TASKI10.ERliOR.PROC->  2, 

P.PB0<»  2, 

T1.PR0<»  2, 

Type2J>R0(»  2, 

T3J»B0<»3, 

R. PH0C->  4, 

S. PR0<»  6, 
othoars*>  -!)); 
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typ«  Acc.TASK.ID  is  accsas  TASX.ID; 

—  Procadnrs  actiTation-racord  types 

type  PiIUM.RECOm>(P:  PHaCEDRUE) ; 
type  PARiN  is  access  PARANJIECORD; 
type  STORE_RECORO(P:  PROCEORCE) ; 
type  STORE  is  access  ST0RE_REC0RD; 
type  STORE.RECORO(P:  PROCEDROE)  is 
record 

OOTER:  STORE; 

PROG:  PROCEDROE: 

PARAMS:  PARAH; 

OLD.DATA:  MACHIHE. DATA. AREA; 
case  P  is 
when  START0P«> 

BUST:  BOOLEAR; 

HAH.TASX:  TASX.ID; 
when  MAIH-> 

I:  IHTEGER:-  1; 

Tl;  TASX.ID; 

when  TERMIIATE.PROC»  null; 

when  TASKZBa.ERRORJ'ROC«>  null; 

when  P  J>ROC»> 

T2:  TASX_1D; 

ACCTHASTER:  RTS.STAGES.KASTER.ID: 

T3;  TASX.ID;  —  Iron  block  B 
when  Tl.PRac«>  ntill: 
when  TTPE2.PR0C«>  null; 
when  T3.FR0C»>  null; 
when  R.PR0C» 

XZ:  Acc.TASX.ID  :■  new  TASX.ID: 
when  S.PROC*> 

T4:  TASX.ID: 
when  othersa>  null; 

end  case; 
end  record; 

type  PARAM.RECORO(P:  PROCEDROE)  is 

record  —  add  paranetar  declarations  hare, 
case  P  is 

when  othera«>  null; 

end  case; 
end  record: 

function  COERCE  is 

new  OICHECXED.COIVERSIOI (STORE,  MACHIHE. DATA. AREA) 
function  COERCE  is 

new  OHCHECXEO.COMTERSIOI(MACHIHB.DATA.AREA.  STORE) 
function  COERCE  is 

new  OICHECXED.COITERSIOI (PARAH,  MACHIHE. DATA. AREA) 
function  COERCE  is 

new  OHCHECXED.COHVERSIOH(HACHI1E.OATA.AREA,  PARAM) 
procedure  OLD  is 

new  OHCHECXEDJ}EALLaCATIOH(STORE.RECORD, STORE); 
procedure  OLD  is 

new  OHCRECXEDJ>£ALLOCATIOH(PARAN.RECORO,PARAM); 
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—  Data  for  siaulatod  tasks. 


TMP:  PAUN: 

ELABORATED:  RTS_STAGES.ACCESS_BOOLEAH:-  ne«  BOOLEAH’ (TRUE) ; 

procedura  ALLOCATECP:  PROCEOROE;  A:  out  MACHINE. OATA.AREA)  is 
begin  A:-  COERCE(naw  STORE.RECORDO*)) ; 
ond  ALLOCATE; 

procedure  CALLCP:  PROCEDRUE;  A:  MACHINE. OATA.AREA)  is 
PA:  PARAM  renanes  COERCE (A) ; 

DA:  STORE:-  nee  ST0RE_REC0RD(P) ; 

ST:  STATE  renanes  CORREST_STA7E(HEHE.CORSE»T_THHEAD); 
begin  DA. OUTER:-  COERCE(ST.DATA) ; 

DA.PROC:-  P; 

for  1  in  LEVEL(P).. LEVEL (COERCECST. DATA) .PROC) 
loop  DA. OOTER:-DA. OUTER. OUTER;  end  loop; 

DA . 0LD.DATA : -ST . DATA ; 

ST. DATA:-  COERCE (DA); 

DA.PARAMS:-  PA; 

begin  ~~  frane  to  insure  tasks  complete 
case  P  is 
vhen  STARTDP-> 

MON_AOA(RERE.CURRENT.THREAO) :-TRUE; 
CLADKRIGHT.TO.START.UP.DA.BUST) ; 
if  not  DA. BUST 

then  RTS .STAGES. CREATE.TASK( 

StZE->  RTS.STAGES.SIZE.TTPECDA'size/STORAGE.UNIT) , 
PRI0->  0. 

HDM_EITRIES->  0, 

MASTER->  RTS.STAGES.CDRREHT.MASTER, 

STATE->  (MAII.COERCE<DA).iaLL.DATA.AHEA), 
LAST.CREATED->  HULL.TASK, 

ELABORATED->  ELABORATED, 

CREATED.TASK->  DA.MAIN.TASK) ; 

R£LEASE(DA.MAII.TASX) ; 
and  if; 

loop  UCE.IDLE.DISPATCH; 
end  loop; 
vhen  MAIl-> 

NOI.AOA(HERE.CURBEHT_THREAO) :-TRDE; 

—  task  Tl; 

RTS .STAGES . CREATE.TASK ( 

SIZE->  RTS.STAGES . SIZE.TTPE (DA ’ sire/STORAGE .UNIT) . 
PRI0->  1, 

IDM.E«TRIES->  0. 

MASTER->  RTS.STAGES. CURREHT.HASTER. 

STATE->  (T1.PR0C,C0ERCE(DA) .NULL.OATA.AREA) , 
LAST_CREATED->  HULL.TASK, 

ELAB0RATED->  ELABORATED, 

CREATED_TASX->  DA.Tl); 

—  X:  INTEGER;-  t; 

DA.X:-  1; 

HTS_STAGES . COMPLETE.ACTIVATION ; 

RTS .STAGES. ACTIVATE.TASKS(DA.Tl) ; 

CHECX(14); 
vhen  P.PROC-> 

RTS  .STAGES  .ENTER  JUSTER; 

—  T2:  TTPE2; 
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RTS _ST AGES . CREATE_TASK ( 

SIZE->  RTS_STAGES.SIZE.nrPE(DA'8ize/ST0RAGE.UIIIT) , 
PRIO->  2, 
mJM_EMTRIES->  0, 

MASTER->  RTS _ST AGES. CORREHT_MASTER, 

STATE->  (TTPE2_PR0C , COERCE (DA) . HDLL.DATA.AREA) , 
LAST_CREATED->  HDLL.TASK, 

ELABORATED«>  ELABORATED, 

CREATED_TASK->  DA.T2) ; 
RTS_STAGES.ACTIVATE_TASKS<DA.T2) ; 

—  typa  ACCT  is  accsss  TYPES; 

DA . ACCTMASTER; -KTS.STAGES . CDRREHT.MASTER; 

CHECK (5); 

RTS.STAGES.ENTERJUSTER;  --  for  block  B 

—  task  T3: 

RTS .STAGES . CREATE.TASK ( 

SI2E->  RTS .STAGES. SIZE_TYPE(D A ’sire/STORAGE. UNIT) , 
PRIO->  3. 

HDM.EHTRIES->  0, 

llASTEK->  RTS.STAGES. CURRENT JIASTER, 

STATE«>  (T3.PR0C , COERCE (DA) . NULL.DATA.AREA) , 
LAST.CREATED->  MULL.TASK, 

ELABORATED->  ELABORATED. 

CREATED.TASK->  DA.T3): 

'rTS .STAGES .  ACnVATE.TASKS  (DA .  T3)  ; 

CHECK (12): 

RTS.STAGES. C011PLETE.MASTER;  --  for  B 
CHECK (13) : 

RTS .STAGES. COMPLETE.HASTER;  —  for  P 
•h«n  Tl.PROC-> 

RTS.STAGES .  COJIPLETE.  ACTIVATION ; 

CHEa(l); 

—  P: 

CALL(P.PBOC,NOLL.DATA.AREA) ; 

CHECK (2) ; 
whan  TTPE2.PRflC-> 

RTS.STAGES . COMPLETE.ACTIVATIOH ; 

CHECK (3): 

if  DA.OUTER.K-l 

then  DA. OUTER. Z:-DA. OUTER. X+l; 

—  P; 

CALL(PJ'ROC.HULL.DATA.AREA) ; 
and  if; 

CHECK (4); 
whan  T3.PR0(» 

RTS.STAGES . COMPLETE.ACTIVATIOH ; 

CHECK(IO); 

—  R; 

CALL(RJ»ROC,IULL.DATA.AREA)  ; 

CHECX(ll); 
whan  R.PROC«> 

CHECK(8); 

—  S; 

CALL(SJ>BOC, NULL.DATA.AREA) ; 

~  if  there  ware  a  paranatar: 

— TMP : -  new  PARAH.RECORO ' ( . . initial  waluas . . ) ; 
~CALL(S  J’ROC , COERCE(TMP)  )  ; 

—OLD  (TMP) ; 

CHEaO); 
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«h«&  S_PROC"> 

RTS.STAGES .  EHTERJIASTER; 

~  T4:  TYPE2; 

RTS.STAGES . CREATE_TASX ( 

SIZE->  RTS_STAGES.SIZE_TYPE(I>A'sis!e/STORAGE.UHIT) . 

PRIO->  2, 

STATE->  (TTPE2_PR0C .COERCE (DA) .HDLL.DATA.AREA) , 
HDM_EHTRIES->  0. 

MASTER->  RTS.STAGES. CORREirr_MASTER. 

LAST.CREATED->  JTOLL.TASK, 

ELABORATED^  ELABORATED. 

CREATED.TASK->  DA.T4) ; 

RTS.STAGES . ACTIVATE.TASKS (DA . T4) ; 

CHECK (6) s 
—  TYPE2; 

RTS.STAGES . CREATE.TASK ( 

SlZE->  RTS.STAGES .  SIZE.TTPE  (DA '  eizo/STORAGE  .IJHIT)  , 

PRIO->  2, 
mm.EHTRIES->  0. 

HASTER>>  DA. OUTER. OUTER. OUTER. ACCTNASTER. 

STATE->  (TYPEOJiROC .COERCE (DA)  .HDLL.DATA.AREA)  . 
LAST.CHEATED->  HDLL.TASK, 

ELABORATED»  ELABORATED. 

CREATED.TASK»  DA. OUTER. XZ. all) ; 

•RTS.STAGES. ACTIVATE.TASKS(DA.ODTER.XX. all) ; 

CHECK (7); 

RTS.STAGES . COMPLETE  JUSTER ; 

«h«n  TERMZIATEJ>ROC» 

RTS.STAGES . COMPLETE.TASK ; 
vhan  TASnHG.ERROR.PROC«> 
raiaa  TASX1BG.ERR0R: 

«ban  oth«rs«> 

ERROR ( "undalinad  PROC.  "); 
and  casa; 

axcaption  vhan  othars«> 

ST. DATA:-  DA.OLD.DATA; 

OLD (DA): 
ralsa; 

and; 

xt  IS.TASK(P)  than  COMPLETE;  RTS.STAGES. COMPLETE.TASK;  and  il; 

ST. DATA:-  DA.OLD.DATA; 

OLD (DA) ; 
end  CALL; 

procedure  DEALLOCATE (A:  in  out  HACHIIE. DATA. AREA)  is 
U:  STORE:-  COERCE(A): 

—  due  to  restriction  RN  6. 4.1 (3)  that  actual  of  OLD  oust  be  a  variable 

—  naae  or  couTersion.  where  COERCE  is  not  recognized  as  a  conversion, 
begin  OLD(AA):  A ; -HULL.DATA.AREA ; 

and  DEALLOCATE; 

begin  IIIT(RICHT.TO_STABT.OP.AVAILABI£->  TRUE); 
end  PROCEDRUES; 


35 


—  tast_4:  siapla  raodazvous  (no  paraaaters) ,  conditional  entry  call, 

—  and  selective  «ait 

with  SYr.-EM; 
package  PKQ_4  is 
task  T1  is 

pragu  PRIORITTd); 
entry  E; 
entry  STOP; 
end  Tl; 
end  PKG_4; 

eitb  CHECKS;  use  CHECKS; 
with  TEXT_I0; 
sith  TRJICE_4; 

pragu  ELiB0RATE(TRACE_4) ; 
package  body  PKG_4  is 
X;  IHTEGER:-  1; 
task  body  Tl  is 
begin  CHECKd); 

accept  E  do  CHECK (2) ; 
end  E; 

CHECK (3); 

accept  E  do  CHECK (4) ; 
end  E; 

CHECK (5); 
select 

accept  E  do  CHECK (6) ; 
end  E; 

CHECK (7); 

else 

CHECK (8); 
end  select; 
select 

accept  E  do  CHECK (9) ; 
end  E; 

CHECK (10); 

else 

CHECK (11); 
end  select; 

accept  STOP  do  CHECK(12) ; 
end  STOP; 

COMPLETE; 
end  Tl; 
and  PKG_4; 

sith  STSTDt; 

eith  CHECKS;  ose  CHECKS; 
vith  PK0_4;  nse  PK0_4; 
procedure  test_4  is 
pragsa  PRIOItrTT(O) ; 
begin  CHECK(13); 

Tl.E; 

Tl.E; 

select 

Tl.E;  CHECK(14); 

else 

CHEadS); 
end  select; 
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s«l«ct 

Tl.E:  CHECX(16); 

•ls« 

CHECK (17); 

«nd  s«l«ct: 

Tl.STOP; 

COMPLETE; 

«ad  t«st_4; 
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—  t€8t.4:  tMts  siapl*  r«nd«ZTOus  (ao  paraa^tcrs),  conditional  entry  call, 
and  select iva  wait 


with  LACE; 

eith  RTS.ABORTIOH: 

with  RIGHTS; 

with  RTS.TASK.IDS; 

vith  tniCHECXED.OEALLOCATIOH; 

with  UICHECXED.COHVERSIQH; 

vith  RTS.STAGES; 

with  RTS.REHDEZVOUS; 

vith  STORAGE; 

vith  RTS_EXCEPTIOHS; 

vith  TRACE_4; 

pragma  ELABORATE  (T1UCE_4} ; 
separate  (MACHIIIE) 
package  body  PROCEDROES  is 

use  LACE; 

use  HACHIHE; 

use  RTS.TASK.IOS; 

subtype  RIGHT  is  RIGHTS. RIGHT; 

procedure  CLAHKR:  RIGHT;  B:  out  BOOLEAH)  renames  RIGHTS. CLAIM; 
procedure  IHIT(R:  in  out  RIGHT; 

AVAILABLE:  BOOLEAH:**  TRUE)  renames  RIGHTS. IHIT; 

RIGHT.TO_START_OP:  RIGHT: 

—  Procedures  (simulated). 

— inJLL_PROCEDRnE:  constant  PROCEDROE:*  0; 

— STARTOP:  constant  PROCEDROE:*  1; 

HAIH:  constant  PROCEDROE:*  2; 

— TERKI1ATE_PR0C:  constant  PROCEDROE:*  3; 

"TASXIIG.ERROR_PROC:  constant  PROCEDROE:*  4; 

Tl.PROC:  constant  PROCEDROE:*  5; 

IS.TASK :  PROCEDRDE_BIT_ VECTOR: *ADA_HAS.SILLT_RESTRICTIOHS ( 
(MAIH|T1J>R0C*>  TROE, 
others*>  FALSE)); 

LEVEL;  PROCEDRDE_IHTEOER_ VECTOR ; *ADA.HAS_3ILLT,RESTRICTI0HS ( 
(HDLL_PROCEDRDE*>  -1, 

STARTDP*>  0, 

1UII*>  1. 

TER)IIHATE_PROC*>  2, 

TASKIHG..ERR0R_PR0C*>  2, 

T1_PR0C*>  2, 
others*>  -1)); 

type  Acc.TASX_IO  is  access  TASX.ID; 

—  Procedure  activation-record  types 

type  PARAKJIECORO(P:  PROCEDROE) ; 
type  PARAX  is  access  PARAX.RECORD; 
type  STOREJtECOROCP:  PROCEDROE); 
type  STORE  is  access  STORE_RECORO: 
type  STORE.RECORO(P:  PROCEDROE)  is 
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record 

OUTER:  STORE; 

PROC:  PROCEDROE; 

PARAHS:  PARAH; 

0U>_DATA:  HACHIHE. DATA. AREA; 
case  P  is 
when  STARTUP>> 

BUST:  BOOLEAI; 

HAII.TASX:TASK_ID: 

«ben  MA1I» 

Tl;  TASK_ID; 

RES:  BOOLEAH; 
when  T1J*R0C*> 

PARAMETER:  RTS.REHOEZVOUS. ACCEPTOR J>ARAHE7ER_0£SCRIPT0R; 
RES2:  RTS.REHDEZVOUS.SEI£CT_IHDEZ: 
when  others~>  null ; 

end  case; 
end  record; 

type  PARAH.RECORDCP:  PROCEDRUE)  la 

record  — ■  add  paraneter  declarationa  here, 
caae  P  is 

when  others»  null; 

end  case; 
end  record; 

function  COERCE  is 

new  UICHECXED.COHVERSIOKSTQRE,  MACRZME. DATA. AREA) ; 
function  COERCE  is 

new  iniCHECXEO.COSTERSIOI(nACHIKE.OATA.AREA.  STORE); 
function  COERCE  is 

new  UlCHECKED.COHTERSIOI (PARAH,  NACHXRE.DATA.AREA) ; 
function  COERCE  is 

new  UVCRECXED.COMTERSIOKMACHIBE.OATAJLREA.  PARAH); 
procedure  OLD  is 

new  UICHECXEO.DEAIXOCATIOH(STORE.RECORD, STORE) ; 
procedure  OLD  is 

new  UHCHECXED_OEALLOCATZOI(PARAM.RECORO. PARAH); 


—  Data  for  sinulated  tasks. 

THP:  PARAH; 

ELABORATED:  RTS.STAGES.ACCESS.BOOLEAI:-  new  BOOLEAI' (TRUE) ; 

procedure  ALLOCATE(P:  PROCEDROE;  A:  out  HACHIIE. DATA. AREA)  is 
begin  A:-  COERCECnew  ST0RE.REC0RD(P)) ; 
end  ALLOCATE; 

procedure  CALL(P:  PROCEDROE;  A:  HACHIIE. DATA.AREA)  is 
PA:  PARAH  renaaes  COERCE (A); 

DA:  STORE:*  new  STOREJIECORO(P)  ; 

ST:  STATE  renames  CURREIT.STATE(HERE.CURREIT.THREAO); 
begin  DA. OUTER:-  COERCE(ST.OATA) ; 

DA. PROC:-  P; 

for  I  in  LETEL(P)..LETEL(COERCE(ST. DATA) .PROC) 
loop  DA. 0DTER:-DA. OUTER. OUTER;  end  loop; 

DA. 0L0.0ATA:-ST. DATA; 

ST. DATA:-  CaEBCE(DA); 
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DA.PXIUNS:*  PA; 

bagin  —  IraM*  to  issora  tasks  coaplata 
casa  P  is 
ohan  STARTDP»> 

HOI_ADA(HEIiE.CURREllT.THREAl)}  i-TRQE: 

CLAIM  (RIGHT.TO.START.TJP .  OA .  BOSY)  ; 

12  not  DA.BUST 

than  RTS_STAGES.CREATE_TASX( 

SIZE->  BTS_STAGES.SIZE_TYPE(DA*aiza/STORAGE.OTrD , 
PRI0->  0, 

BDM_EHTIIIES»  0. 

MASTER»  RTS_STAGES.ajRREirr_HASTER. 

STATE»  (MAH,  COERCE  (DA)  .HDLL.DATA.AREA) , 
LAST_CREATED»  BDLL.TASK, 

ELAB0RATED->  ELABORATED. 

CR£ATED_TASK«>  DA.MAH.TASX)  ; 

RELEASE (DA. MAIH.TASK) ; 
and  12; 

loop  IDLE_DISPATCH; 
and  loop: 


whan  MA1I» 

H0I_ADA(BERE. CORREHT.THREAD) :-TR0E ; 
task  Tl; 

RTS .STAGES . CREATE.TASX ( 

SIZE->  RTS.STAGES.SZZE_T?PE(DA’siza/STORAGE.UHIT} , 

PR10->  1. 

BOM_EHTBIES->  1. 

NASTERp>  RTS.STAGES.CQRREIT.HASTER. 

STATE->  (Tl J'BOC.COERCE(DA)  .BDLL.DATA.AREA) , 

LAST.CREATED->  HOLL.TASK, 

ELABORATED>>  ELABORATED, 

CREATED.TASK->  DA.Tl); 

RTS_STAGES . COMPLETE. ACTIVATIOI ; 

RTS.STAGES.ACTIVATE.TASKS(DA.Tl) ; 

CBECXdS); 

—  naka  antry  call:  Tl.E;  SI 
RTS.REIDEZVOUS .  CALL.SIMPIZ  (ACCEPTOR»DA.  Tl . 

E->  1, 

PARAMETER»(1DLL.DATA.AREA  .0)  } ; 

—  naka  antxy  call:  Tl.E;  #2 
RTS.REIDEZVOUS . CALL.SIMPLE (ACCEPTOR->DA . Tl . 

E->  1, 

PARAMETER«>(]IDU.DATA.AREA.O)) ; 

— salact  Tl.E  alsa  noil;  and  salact;  S3 
RTS.REHDEZVODS . CALL.COHOinOIAL(ACCEPTOR*>OA. Tl . 

E->  1, 

PARAMEIER»(IDLL.DATA.AREA,0) . 
REIDEZYOOS.SaCCESSFOL->  DA. RES); 
—salact  Tl.E  alsa  null;  and  salact;  S4 
12  DA. RES 

than  CHECK(14);  alsa  CBECKdS);  and  12; 

RTS  JIEIDEZVOOS . CALL.COn)rnOIAL( ACCEPTQR*>DA. Tl . 

E->  1, 

PARAMETER-XBnLL.DATA.AREA.0} , 
REIDEZ700S.SaCCESSFaL»  DA. RES); 

12  DA. RES 

than  CHECXdS):  alsa  CBECXdY);  and  12; 

—  saks  antxy  call:  Tl.STOP; 
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RTS_REMDEZVaOS . CAIX_SIMPtE(ACCEPTOR->DA.Tl. 

E->  2. 

PiUUMETER->(HnLL_DATA_ABEA ,0)  )  ;  • 


«h€n  T1_PR0(» 

RTS.STAGES . COMPLETE_ACTIVATIQI ; 

—  accept  E;  #1 

RTS.REin)EZVODS.ACCEPT_CALL(E»  1. 

PARAMETER»  DA. PARAMETER) ; 

begin  CHECK (2); 

RTS.REHDEZVOUS . COHPLETE.REHDEZVODS ; 
exception 

vhen  othera->  RTS.REHDEZVaDS.EXCEPnOKAL.CONPLETE.RENDEZVCIUS 
<RTS_EXCEPTiaiS  .CDRflEBrr.EXCEPTIOH) ; 

end: 

CHECK (3) : 

—  accept  E;  #2 

RTS.REHDEZVOOS . ACCEPT.CALL (E->  1. 

PARAHETER»  DA. PARAMETER) ; 

begin  CHECK (4); 

RTS_REHDEZVaxra . COMPLETE.RENDEZVODS ; 
exception 

'  when  othexa»  RTS.REHDEZVOOS. EZCEPTXOHAL.COMPLETE.REHDEZVODS 
(RTS.EXCEPT10IS .CaRREHT_EXCEPTIOH) ; 

end; 

CHECK (S): 

—  aelect  accept  E;  ft3 
■—  else  null; 

end  select; 

RTS_REHDEZVaOS.SELECTI7E_¥AIT(aPEH.EHTRIES->(l. . 1->1) , 

D«>  0.0, 

SELECT.Mai£->  RTS.REHDEZVOOS.£LSEJ{ODE. 
PARAHETER->  DA.PARAMETER, 

IHDEZ->  0A.RES2): 

case  DA.RES2  is 
ehen  1«> 
begin 
CHECK(6); 

RTS.REHDEZVOOS . COMPLETE_REHDEZVaOS ; 
exception 

when  others>>  RTS.REHDEZVOOS. EXCEPTZOHAL.COMPLETE.REHDEZVOOS 
(RTS.EXCEPTIOHS . CORRERT.EZCEPTZOR) ; 

end: 

CHECK (7); 

when  others>>  CHECK (8) ; 
end  case; 

—  select  accept  E; 

—  else  null; 
end  select: 

RTS.REHDEZV003  .SELECnVE.WAlTCOPEH  JHTRIZS-Xl . .  1->1)  . 

0->  0.0, 

SELECT.MODE->  RTS.REBDEZVOOS.ELSE.HOOE, 
PARAMETBR->  DA.PARAMETER, 

IHDEZ->  DA.RES2): 


case  DA.RES2  is 
when  1>> 
begin 

CHECK (9); 
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RTS_R£ltDEZVOUS .  COHPLETE_REin)EZVOnS : 

•xception 

■ban  othars«>  IlTS_REHDEZVaUS.EXCEPTIOHAL_COMFL£TE_IIENDEZVOnS 
(RTS_EXCEPnOHS  .iCURREHT.EXCEPnOH) ; 

•nd; 

CHECK (10): 

whan  otharsa'>  CHECX(ll); 
and  casa; 

—  accept  STOP; 

RTS_REiroEZVOOS.ACCEPT_CAII.(E->  2. 

PARAMETERS  DA. PARAMETER) ; 

begin  CHECK (12); 

RTS.REHDEZVOUS . COMPLETE.REHDEZVQDS ; 
exception 

when  othara->  RTS_REHDEZVaOS.EXCEPTIOHAL_COMPLETE_REiroEZVOOS 
(RTS_EXCEPTIQHS.CORRENT_EICEPTIOH) ; 

and; 

vhan  TERMIlATE_PROC-> 

RTS.3TAGES , COMPLETE.TASK ; 
when  TASKIlG_ERROR_PROC-> 
raise  TASKZHG.ERROR; 
vhan  otharss 

POTCnadaiinad  PROC.  “); 

'PCrT_LIlE  (PRaCEORIlE '  inaga  (P)  ) ; 
raise  PRaGRAM_ERROR; 
and  case; 

axcaption  vhan  otharss 

ST. DATA:*  DA.OLD.OATA; 

OLOCDA) : 
raise; 

and: 

ii  IS.TASK(P)  than  COMPLETE;  RTS.STAGES.COMPLETE.TASK;  end  il; 

ST. DATA:-  DA.OLD.DATA; 

OLO(DA) : 
and  CALL; 

procadura  DEALLaCATE(A:  in  out  MACHIHE. DATA. AREA)  is 
AA:  STORE:-  CQERCE(A); 

doe  to  restriction  RH  6. 4. 1(3)  that  actual  of  OLD  nst  be  a  variable 
nane  or  conversion,  vhere  COERCE  is  not  recognized  as  a  conversion, 
begin  OLO(U);  A:-IDLL_DATA.AREA; 

•ad  DEALLOCATE; 

begin  ZlZT(RIGHT.TO_3TART.OP,ATAILABLE->  TROE) ; 
end  PROCEDHDES ; 


